저는 AWS의 수백 대의 시스템에 영향을 미치는 메모리 문제를 다루고 있습니다. 120GB RAM을 갖춘 i3.4xl 인스턴스입니다. Docker 컨테이너 내에서 실행되는 Java 데이터베이스 서버는 대부분의 RAM을 소비하지만 보고된 "사용된 메모리" 지표가 프로세스 사용량보다 훨씬 높다는 것을 관찰했습니다.
~$ free -m
total used free shared buff/cache available
Mem: 122878 105687 11608 1221 5583 14285
Swap: 0 0 0
상단의 스냅샷은 다음과 같습니다. 사용된 메모리 108GB 중 데이터베이스는 77GB만 차지합니다.
top - 18:21:25 up 310 days, 15:48, 1 user, load average: 23.78, 20.90, 24.30
Tasks: 284 total, 2 running, 282 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.4 us, 3.9 sy, 0.0 ni, 83.5 id, 0.2 wa, 0.0 hi, 0.9 si, 1.1 st
KiB Mem : 12582788+total, 7280872 free, 10839378+used, 10153232 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 14414696 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
45338 root 20 0 88.304g 0.077t 24460 S 396.7 65.9 4962:44 java
1353 consul 20 0 53784 30068 0 S 1.3 0.0 10030:05 consul
82080 root 24 4 979740 46128 8548 S 1.3 0.0 6:46.95 aws
2941 dd-agent 20 0 194848 23548 3068 S 1.0 0.0 1293:05 python
83 root 20 0 0 0 0 S 0.3 0.0 290:30.49 ksoftirqd/15
503 root 20 0 147352 98228 87492 S 0.3 0.1 994:49.08 systemd-journal
964 root 20 0 0 0 0 S 0.3 0.0 1031:29 xfsaild/nvme0n1
1405 root 20 0 1628420 48796 16588 S 0.3 0.0 533:50.58 dockerd
2963 dd-agent 20 0 4184188 241520 1196 S 0.3 0.2 168:24.64 java
28797 xray 20 0 3107132 236288 4724 S 0.3 0.2 150:04.44 xray
116185 root 20 0 1722788 13012 6348 S 0.3 0.0 53:54.38 amazon-ssm-agen
1 root 20 0 38728 6144 3308 S 0.0 0.0 2:41.84 systemd
2 root 20 0 0 0 0 S 0.0 0.0 399:59.14 kthreadd
그리고 /proc/meminfo:
~# cat /proc/meminfo
MemTotal: 125827888 kB
MemFree: 5982300 kB
MemAvailable: 14354644 kB
Buffers: 2852 kB
Cached: 9269636 kB
SwapCached: 0 kB
Active: 86468892 kB
Inactive: 6778036 kB
Active(anon): 83977260 kB
Inactive(anon): 1259020 kB
Active(file): 2491632 kB
Inactive(file): 5519016 kB
Unevictable: 3660 kB
Mlocked: 3660 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 220968 kB
Writeback: 0 kB
AnonPages: 83978456 kB
Mapped: 182596 kB
Shmem: 1259060 kB
Slab: 2122036 kB
SReclaimable: 1131528 kB
SUnreclaim: 990508 kB
KernelStack: 48416 kB
PageTables: 183468 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 62913944 kB
Committed_AS: 89880700 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 28672 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 4868096 kB
DirectMap2M: 120961024 kB
DirectMap1G: 4194304 kB
설정을 통해 태블릿 캐시를 보다 적극적으로 재활용하기 위해 이전에 몇 가지 사항을 변경했습니다.
~# cat /proc/sys/vm/vfs_cache_pressure
1000
/proc/meminfo의 태블릿 메모리는 15GB 이상으로 보고되었지만 현재는 약 2GB로 유지됩니다. 다음은 슬랩탑 출력입니다(편집 시 추가됨, 아래 캐시를 삭제한 후 메모리가 다시 채워지기 시작할 때).
Active / Total Objects (% used) : 7068193 / 7395845 (95.6%)
Active / Total Slabs (% used) : 158330 / 158330 (100.0%)
Active / Total Caches (% used) : 81 / 128 (63.3%)
Active / Total Size (% used) : 2121875.02K / 2188049.35K (97.0%)
Minimum / Average / Maximum Object : 0.01K / 0.29K / 8.00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
1465206 1464982 99% 0.38K 35375 42 566000K mnt_cache
1360044 1360044 100% 0.19K 32383 42 259064K dentry
1175936 1107199 94% 0.03K 9187 128 36748K kmalloc-32
1056042 1055815 99% 0.10K 27078 39 108312K buffer_head
732672 727789 99% 1.06K 24606 30 787392K xfs_inode
462213 453665 98% 0.15K 8721 53 69768K xfs_ili
333284 333250 99% 0.57K 6032 56 193024K radix_tree_node
173056 117508 67% 0.06K 2704 64 10816K kmalloc-64
90336 31039 34% 0.12K 1414 64 11312K kmalloc-128
82656 23185 28% 0.19K 1972 42 15776K kmalloc-192
58328 40629 69% 0.50K 1012 64 32384K kmalloc-512
51476 51476 100% 0.12K 758 68 6064K kernfs_node_cache
45440 15333 33% 0.25K 713 64 11408K kmalloc-256
21250 21250 100% 0.05K 250 85 1000K ftrace_event_field
20706 20298 98% 0.04K 203 102 812K ext4_extent_status
19779 18103 91% 0.55K 347 57 11104K inode_cache
18600 18600 100% 0.61K 363 52 11616K proc_inode_cache
14800 13964 94% 0.20K 371 40 2968K vm_area_struct
14176 6321 44% 1.00K 443 32 14176K kmalloc-1024
12006 12006 100% 0.09K 261 46 1044K trace_event_file
11776 11776 100% 0.01K 23 512 92K kmalloc-8
그러나 슬랩 캐싱으로 인해 여전히 메모리 사용량이 높아집니다. 나는 그것을 버릴 수 있기 때문에 이것을 믿습니다.
~# echo 2 > /proc/sys/vm/drop_caches
그러면 다음이 표시됩니다.
~# free -m
total used free shared buff/cache available
Mem: 122878 82880 36236 1245 3761 37815
Swap: 0 0 0
/proc/meminfo에는 2GB의 메모리만 표시되지만 태블릿 캐시를 삭제하면 20GB 이상의 메모리가 확보됩니다. 이것은 새로운 /proc/meminfo입니다:
~# cat /proc/meminfo
MemTotal: 125827888 kB
MemFree: 34316592 kB
MemAvailable: 38394188 kB
Buffers: 6652 kB
Cached: 5726320 kB
SwapCached: 0 kB
Active: 85651988 kB
Inactive: 4084612 kB
Active(anon): 84007364 kB
Inactive(anon): 1283596 kB
Active(file): 1644624 kB
Inactive(file): 2801016 kB
Unevictable: 3660 kB
Mlocked: 3660 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 260096 kB
Writeback: 0 kB
AnonPages: 84008564 kB
Mapped: 194628 kB
Shmem: 1283636 kB
Slab: 601176 kB
SReclaimable: 401788 kB
SUnreclaim: 199388 kB
KernelStack: 48496 kB
PageTables: 183564 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 62913944 kB
Committed_AS: 89815920 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 28672 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 4868096 kB
DirectMap2M: 120961024 kB
DirectMap1G: 4194304 kB
그래서 내 질문은 왜 이런 일이 발생하며 슬랩 캐시가 사용된 메모리에 너무 많은 영향을 미치는 것을 방지하려면 어떻게 해야 할까요? 결국 Java 서버가 oom-kill 상태가 되지만 페이지 캐싱이 더 효율적으로 되는 것을 방해할 수도 있습니다. Java 서버는 파일 시스템(XFS)에서 많은 수(수백만)의 파일을 다루므로 이것이 관련이 있을 수 있지만 보고된 측정항목이 일관되지 않는 이유를 이해할 수 없습니다. 이는 동일한 방식으로 구성된 수백 대의 시스템에 다시 영향을 미쳤습니다.
어떤 도움이라도 대단히 감사하겠습니다. 감사합니다!