한동안 Debian 웹 서버(VPS/VM)에서 RAM 부족을 경험했습니다. 자주 발생하는 경우 이는 이상한 일이 아닙니다. 하지만 그들은 그렇지 않았습니다. Munin의 차트는 다음과 같습니다.
이러한 퍼즐을 해결하기 위해 시스템 추적을 사용합니다 atop. 다음은 RAM 부족 중 및 이후 오전 7시와 오전 9시의 두 스냅샷입니다( -m메모리 관련 정보 보기 옵션 사용).
ATOP - <snip> 2014/09/10 07:00:02 ------ 10m0s elapsed
<snip>
MEM | tot 2.0G | free 79.1M | cache 102.4M | dirty 0.1M | buff 53.2M | slab 90.8M | | |
SWP | tot 2.0G | free 2.0G | | | | | vmcom 748.1M | vmlim 3.0G |
DSK | sda | busy 1% | read 917 | write 1695 | KiB/w 13 | MBr/s 0.01 | MBw/s 0.04 | avio 1.22 ms |
<snip>
PID MINFLT MAJFLT VSTEXT VSIZE RSIZE VGROW RGROW RUID EUID MEM CMD 1/15
13717 102 18 10709K 874.5M 206.2M 0K 128K mysql mysql 10% mysqld
4086 166 0 450K 228.1M 21896K 0K 0K www-data www-data 1% apache2
19131 1659 99 450K 225.5M 19604K -2652K -2292K www-data www-data 1% apache2
1469 608 0 450K 222.6M 18508K 256K 64K www-data www-data 1% apache2
23038 347 0 450K 222.3M 18496K 0K 0K www-data www-data 1% apache2
4085 721 0 450K 222.1M 18308K 0K 0K www-data www-data 1% apache2
10639 790 0 450K 224.9M 18284K 768K 932K www-data www-data 1% apache2
19158 199 1 450K 222.1M 18064K 0K 52K www-data www-data 1% apache2
1895 330 0 450K 221.8M 18020K 0K 0K www-data www-data 1% apache2
6661 3346 22 450K 224.0M 17700K 1512K -780K www-data www-data 1% apache2
12570 808 0 450K 221.7M 17668K 512K 508K www-data www-data 1% apache2
19817 0 0 450K 214.5M 15336K 0K 0K root root 1% apache2
18209 3996 0 2277K 55592K 14728K 55592K 14728K till till 1% python
18210 2760 0 4K 43292K 10544K 43292K 10544K munin munin 1% munin-update
11976 506 0 149K 18788K 6512K 0K 0K root root 0% atop
1934 175 0 4K 52228K 5852K 0K 0K root root 0% munin-node
17993 0 0 4K 67020K 5712K 0K 0K postgrey postgrey 0% /usr/sbin/post
2000 0 0 346K 244.3M 5668K 0K 0K root root 0% rsyslogd
14557 0 0 7163K 234.9M 5284K 0K 0K root root 0% php5-fpm
14558 0 0 7163K 234.9M 4564K 0K 0K www-data www-data 0% php5-fpm
14559 0 0 7163K 234.9M 4564K 0K 0K www-data www-data 0% php5-fpm
328 0 0 134K 572.6M 2932K 0K 0K root root 0% console-kit-da
<snip>
그리고...
ATOP - vmd1989 2014/09/10 09:00:02 ------ 10m0s elapsed
<snip>
MEM | tot 2.0G | free 1.5G | cache 88.8M | dirty 0.1M | buff 19.2M | slab 25.8M | | |
SWP | tot 2.0G | free 2.0G | | | | | vmcom 748.0M | vmlim 3.0G |
DSK | sda | busy 0% | read 453 | write 1991 | KiB/w 12 | MBr/s 0.01 | MBw/s 0.04 | avio 1.01 ms |
<snip>
PID MINFLT MAJFLT VSTEXT VSIZE RSIZE VGROW RGROW RUID EUID MEM CMD 1/16
13717 189 0 10709K 874.5M 206.3M 0K 0K mysql mysql 10% mysqld
23038 743 7 450K 222.6M 18620K 0K 40K www-data www-data 1% apache2
23930 692 0 450K 220.6M 18568K 0K 0K www-data www-data 1% apache2
28738 4784 0 4K 126.4M 18328K 126.4M 18328K munin munin 1% munin-update
26990 392 1 450K 220.5M 18088K 0K 112K www-data www-data 1% apache2
26552 1150 2 450K 220.3M 17788K 512K 576K www-data www-data 1% apache2
28744 1443 0 4K 129.1M 17636K 129.1M 17636K munin munin 1% /usr/share/mun
27424 602 0 450K 219.8M 17504K 8K 240K www-data www-data 1% apache2
27000 216 0 450K 219.8M 17308K 8K 104K www-data www-data 1% apache2
28290 2977 0 450K 219.9M 17200K 219.9M 17200K www-data www-data 1% apache2
19817 68 0 450K 214.5M 15340K 0K 0K root root 1% apache2
28287 429 1 450K 215.0M 10384K 215.0M 10384K www-data www-data 1% apache2
28727 184 0 450K 214.5M 9300K 214.5M 9300K www-data www-data 0% apache2
28728 191 0 450K 214.5M 9300K 214.5M 9300K www-data www-data 0% apache2
11976 490 0 149K 18788K 6512K 0K 0K root root 0% atop
1934 428 0 4K 52228K 5852K 0K 0K root root 0% munin-node
2000 0 0 346K 244.3M 5668K 0K 0K root root 0% rsyslogd
28745 1036 0 4K 52228K 5580K 52228K 5580K root root 0% munin-node [::
14557 0 0 7163K 234.9M 5284K 0K 0K root root 0% php5-fpm
17993 0 0 4K 67020K 4844K 0K 0K postgrey postgrey 0% /usr/sbin/post
14558 0 0 7163K 234.9M 4564K 0K 0K www-data www-data 0% php5-fpm
14559 0 0 7163K 234.9M 4564K 0K 0K www-data www-data 0% php5-fpm
328 0 0 134K 572.6M 2932K 0K 0K root root 0% console-kit-da
<snip>
목록이 길어서 죄송합니다. 이유를 놓치고 싶지 않았습니다. 그러나 내 문제는 이유를 알 수 없다는 것입니다. 상태(상단)에는 확실히 "여유" 메모리가 적지만 그 이유와 메모리가 어디로 가는지 설명할 수 있는 프로세스가 없습니다.
내 생각이 틀렸나요?
고쳐 쓰다
Patrick의 제안에 따라 /proc/meminfoRAM 부족 단계와 그 이후에 수집했습니다. 쉽게 볼 수 있도록 내용을 표에 넣었습니다.
mem-shortage a bit later
MemTotal: 2060776 kB 2060776 kB
MemFree: 252896 kB 1608532 kB *
Buffers: 15464 kB 12060 kB
Cached: 71864 kB 62800 kB
SwapCached: 4160 kB 4160 kB
Active: 268020 kB 253368 kB
Inactive: 134988 kB 132300 kB
Active(anon): 225940 kB 220872 kB
Inactive(anon): 97296 kB 220872 kB *
Active(file): 42080 kB 32496 kB
Inactive(file): 37692 kB 29116 kB
Unevictable: 6540 kB 6680 kB
Mlocked: 6540 kB 6680 kB
SwapTotal: 2096476 kB 2096476 kB
SwapFree: 2081568 kB 2081568 kB
Dirty: 0 kB 116 kB
Writeback: 0 kB 0 kB
AnonPages: 318084 kB 313364 kB
Mapped: 20692 kB 20408 kB
Shmem: 4208 kB 9896 kB
Slab: 24336 kB 23936 kB
SReclaimable: 10252 kB 9316 kB
SUnreclaim: 14084 kB 14620 kB
KernelStack: 1464 kB 1544 kB
PageTables: 8396 kB 9544 kB
NFS_Unstable: 0 kB 0 kB
Bounce: 0 kB 0 kB
WritebackTmp: 0 kB 0 kB
CommitLimit: 3126864 kB 3126864 kB
Committed_AS: 744764 kB 761812 kB
VmallocTotal: 34359738367 kB 34359738367 kB
VmallocUsed: 272976 kB 272976 kB
VmallocChunk: 34359464431 kB 34359464431 kB
HardwareCorrupted: 0 kB 0 kB
AnonHugePages: 0 kB 0 kB
HugePages_Total: 0 0
HugePages_Free: 0 0
HugePages_Rsvd: 0 0
HugePages_Surp: 0 0
Hugepagesize: 2048 kB 2048 kB
DirectMap4k: 282560 kB 282560 kB
DirectMap2M: 1814528 kB 1814528 kB
별표(*)로 표시된 두 가지 중요한(통계적으로 유의하지 않은) 차이점만 볼 수 있지만 RAM이 어디로 갔는지 알려주지 않는 것 같습니다.
또한 공유 메모리도 확인했지만(가능한 한 최선을 다해)... 아무것도 찾지 못했습니다.
# ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
또한 검사를 사용하여 프로세스를 숨깁니다 unhide. 그러나 거짓 긍정(Debian의 알려진 문제) 외에는 숨겨진 프로세스가 없는 것 같습니다.
1.2GB RAM이 사용되는 이유에 대한 더 많은 아이디어가 있습니까? 이것이 가상 서버 아키텍처로 인해 발생하는 또 다른 문제입니까?
고쳐 쓰다
lsmod나는 Sergio의 지시에 따라 메모리 팽창을 상담 하고 확인했습니다. 칼럼 size에는 유용한 내용은 없지만 프로세스가 있으므로 vmw_balloon실제로는 VM 간 메모리 이동에 문제가 있는 것으로 보입니다. 질문에 답변되었습니다 :)
# During high RAM usage (removed middle part)
$ lsmod | sort -r -k 2,2n
Module Size Used by
crc16 12343 1 ext4
crc_t10dif 12348 1 sd_mod
libcrc32c 12426 2 xfs,btrfs
mperf 12453 0
ata_generic 12490 0
pcspkr 12632 0
vmw_balloon 12657 0 <=
ac 12668 0
i2c_piix4 12704 0
coretemp 12898 0
<snip>
reiserfs 193501 0
drm 211856 2 ttm,vmwgfx
ext4 381419 1
xfs 628913 0
btrfs 641551 0
답변1
어쩌면 가상 머신에 어떤 문제가 있을 수도 있습니다.기억의 팽창가상화 플랫폼에서 명령되는 작업입니다. 관련 모듈을 찾아 이를 확인할 수 있습니다.lsmod(이름은 가상화 플랫폼마다 다르지만 매우 고유해야 합니다.)
메모리 벌루닝이 활성화되면 가상화 호스트는 필요할 때 한 VM에서 다른 VM으로 메모리 리소스를 이동할 수 있습니다. 해당 호스트의 요청에 따라 게스트의 커널 모듈은 지정된 수의 커널 모듈을 예약합니다.물리적RAM(게스트에서 실행되는 운영 체제의 관점에서 볼 때 물리적)은 다른 프로세스에서 이를 사용할 수 없도록 합니다. 그런 다음 호스트는 실제 물리적 리소스를 다른 게스트에게 재할당합니다.
손님에게 미치는 영향은 바로 여러분이 보고 있는 것과 같습니다. 뚜렷한 소유자 없이 많은 메모리가 사용됩니다.
가상화 플랫폼을 제어할 수 없는 경우 가상 머신 벌루닝 매개변수의 실제 구성에 대해 공급자에게 문의해야 합니다.