しばらくDebian Webサーバー(VPS / VM)でRAMの不足を経験しました。頻繁に発生する場合、これは奇妙なことではありません。しかし、彼らはそうではありませんでした。 Muninのチャートは次のとおりです。
これらのパズルを解決するためにシステムトレースを使用してくださいatop
。以下は、RAMが不足している場合とそれ以降の午前7時と午前9時の2つのスナップショットです(-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>
リストが長くてすみません。理由を見逃したくなかった。しかし、私の問題は理由がわからないということです。状態(上部)には確かに「空き」メモリが少なくなりますが、その理由とメモリがどこに行くかを説明できるプロセスはありません。
私の考えが間違っていますか?
修正する
パトリックの提案に従って、/proc/meminfo
RAM不足の段階とそれ以降に収集しました。見やすいように内容を表に入れました。
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
アスタリスク(*)で示されている2つの重要な(統計的に有意ではない)違いだけを見ることができますが、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(ゲストで実行されているオペレーティングシステムの観点からは物理的)は、他のプロセスで使用できないようにします。その後、ホストは実際の物理リソースを他のゲストに再割り当てします。
ゲストに与える影響は、あなたが見ているのと同じです。明確な所有者なしで多くのメモリが使用されます。
仮想化プラットフォームを制御できない場合は、仮想マシンバルーンパラメータの実際の構成についてプロバイダに連絡する必要があります。