メモリのスワップ領域の空き容量が0になってしまいます。

Question

お世話になります。

現在、稼働中のWebサーバにて、物理メモリの空き容量があるにもかかわらず、スワップ領域を100%使ってしまい、スワップ領域の空きがないという現象が発生しております。
改善を図るにはどうしたらよいでしょうか。
OSはCentOS6.4です。

以下に、関連すると思われるコマンドの出力を羅列します。

$ free
             total       used       free     shared    buffers     cached
Mem:      16443276    5096000   11347276          0     332164    3360440
-/+ buffers/cache:    1403396   15039880
Swap:      4095992    4095992          0

Swapのfreeが0になっています。

$ uname -a
Linux localhost.localdomain 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/redhat-release 
CentOS release 6.4 (Final)

$ cat /proc/meminfo
MemTotal:       16443276 kB
MemFree:        11393580 kB
Buffers:          332164 kB
Cached:          3369660 kB
SwapCached:        90288 kB
Active:          3399304 kB
Inactive:        1158360 kB
Active(anon):    2401504 kB
Inactive(anon):   580472 kB
Active(file):     997800 kB
Inactive(file):   577888 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       4095992 kB
SwapFree:              0 kB
Dirty:                24 kB
Writeback:             0 kB
AnonPages:        765552 kB
Mapped:            25476 kB
Shmem:           2126136 kB
Slab:             349232 kB
SReclaimable:     305408 kB
SUnreclaim:        43824 kB
KernelStack:        1624 kB
PageTables:        19376 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    12317628 kB
Committed_AS:    7510372 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      304364 kB
VmallocChunk:   34359429240 kB
HardwareCorrupted:     0 kB
AnonHugePages:    507904 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        4096 kB
DirectMap2M:     2084864 kB
DirectMap1G:    14680064 kB

$ cat /proc/sys/vm/swappiness
60

swappinessは出来る限り変更せずに解決したいです。

top - 14:34:54 up 790 days, 13:59,  3 users,  load average: 0.06, 0.06, 0.07
Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.6%us,  0.4%sy,  0.0%ni, 97.4%id,  0.6%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16443276k total,  5113416k used, 11329860k free,   332164k buffers
Swap:  4095992k total,  4095992k used,        0k free,  3370900k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP COMMAND
 1799 root      20   0 98.1m 1884 1092 S  0.0  0.0  13:52.34  18m miniserv.pl
19704 root      20   0 6057m  66m 9936 S  0.0  0.4  75:38.55 3692 java
 1963 root      20   0 97.9m 1244  788 S  0.0  0.0 188:02.48 3000 snmpd
 1620 root      20   0 15080  584  580 S  0.0  0.0   0:00.00 2228 config
 1531 root      20   0  247m 9.8m  760 S  1.0  0.1   7655:18  916 lsi_mrdsnmpagen
 1708 root      20   0 78728 2016 1916 S  0.0  0.0   3:03.50  760 master
 1717 postfix   20   0 78980 2024 1868 S  0.0  0.0   0:43.42  748 qmgr
 6006 root      20   0 64116  624  520 S  0.0  0.0   6:04.32  568 sshd
 1726 root      20   0 20408  760  672 S  0.0  0.0   4:23.37  552 crond
 1608 root      20   0 52104  192  188 S  0.0  0.0   0:00.00  500 vsftpd
  555 root      16  -4 10676  312  308 S  0.0  0.0   0:00.07  456 udevd
 1603 root      20   0 52104  292  236 S  0.0  0.0   0:00.19  452 vsftpd
10811 root      18  -2 10672  260  256 S  0.0  0.0   0:00.00  452 udevd
10812 root      18  -2 10672  200  196 S  0.0  0.0   0:00.00  452 udevd
 1462 haldaemo  20   0 25504 1848 1088 S  0.0  0.0   5:24.76  352 hald
15046 ntp       20   0 30160 1204 1072 S  0.0  0.0   0:38.62  320 ntpd
 1380 root      20   0  244m 5520  872 S  0.0  0.0   8:16.67  296 rsyslogd
 1618 root      20   0 13104  648  644 S  0.0  0.0   0:00.00  272 log
 1615 root      20   0 19256  348  344 S  0.0  0.0   0:00.00  224 dovecot
 1463 root      20   0 18104  764  760 S  0.0  0.0   0:00.01  196 hald-runner
 1491 root      20   0 20248  808  804 S  0.0  0.0   0:00.01  168 hald-addon-inpu
 1617 dovecot   20   0 12972  600  596 S  0.0  0.0   0:00.00  164 anvil
 1737 root      20   0 21452  312  292 S  0.0  0.0   0:00.42  160 atd
 1438 dbus      20   0 21400  808  624 S  0.0  0.0   0:03.54  116 dbus-daemon
 1430 root      20   0 10884  532  412 S  0.0  0.0 103:31.64  100 irqbalance
    1 root      20   0 19352 1292 1076 S  0.0  0.0   1:27.79   92 init
 1505 haldaemo  20   0 17804  936  852 S  0.0  0.0   0:00.66   72 hald-addon-acpi
 1810 root      20   0  4060  460  456 S  0.0  0.0   0:00.00   64 mingetty
 1812 root      20   0  4060  460  456 S  0.0  0.0   0:00.00   64 mingetty
 1814 root      20   0  4060  460  456 S  0.0  0.0   0:00.00   64 mingetty
 1816 root      20   0  4060  460  456 S  0.0  0.0   0:00.00   64 mingetty
 1818 root      20   0  4060  460  456 S  0.0  0.0   0:00.00   64 mingetty
25336 root      20   0  4060  456  452 S  0.0  0.0   0:00.00   64 mingetty
 1453 root      20   0  4076  560  504 S  0.0  0.0   0:00.16   52 acpid

topコマンドをSwap順にソートしています。

top - 14:43:00 up 790 days, 14:07,  3 users,  load average: 0.02, 0.08, 0.08
Tasks: 169 total,   2 running, 167 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.3%us,  0.3%sy,  0.0%ni, 97.2%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16443276k total,  5119408k used, 11323868k free,   332164k buffers
Swap:  4095992k total,  4095992k used,        0k free,  3374408k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
19704 root      20   0 6057m  66m 9936 S  0.0  0.4  75:38.82 java
31465 apache    20   0  337m  52m 5520 S  0.7  0.3   0:01.03 httpd
31224 apache    20   0  336m  52m 6184 S  0.0  0.3   0:20.18 httpd
31317 apache    20   0  335m  51m 5924 S  0.3  0.3   0:09.55 httpd
31327 apache    20   0  332m  48m 5928 S  0.7  0.3   0:12.33 httpd
31375 apache    20   0  332m  48m 5888 S  0.3  0.3   0:07.18 httpd
31158 apache    20   0  332m  48m 5892 S  0.3  0.3   0:15.36 httpd
31326 apache    20   0  330m  46m 6008 S  0.3  0.3   0:12.13 httpd
31380 apache    20   0  330m  46m 5976 S  0.3  0.3   0:06.99 httpd
31377 apache    20   0  329m  45m 5888 S  0.7  0.3   0:06.20 httpd
31467 apache    20   0  329m  45m 5852 S  0.3  0.3   0:02.61 httpd
31250 apache    20   0  328m  44m 5920 S  0.3  0.3   0:16.33 httpd
31459 apache    20   0  328m  44m 5884 S  0.3  0.3   0:03.48 httpd
31460 apache    20   0  328m  44m 5888 S  0.3  0.3   0:02.59 httpd
31331 apache    20   0  328m  44m 5924 S  0.7  0.3   0:13.09 httpd
31461 apache    20   0  325m  40m 5896 S  0.7  0.3   0:01.14 httpd
31283 apache    20   0  324m  40m 6092 S  0.3  0.3   0:10.86 httpd
31318 apache    20   0  324m  40m 5924 S  0.3  0.3   0:14.48 httpd
31379 apache    20   0  324m  40m 5976 S  0.3  0.3   0:08.05 httpd
30750 apache    20   0  324m  40m 6112 S  0.7  0.3   0:44.45 httpd
31466 apache    20   0  324m  40m 5888 S  0.7  0.3   0:01.78 httpd
16068 root      20   0  296m  16m 8760 S  0.0  0.1   5:46.89 httpd
 1531 root      20   0  247m 9.8m  760 S  0.3  0.1   7655:22 lsi_mrdsnmpagen
 1380 root      20   0  244m 5520  872 S  0.0  0.0   8:16.67 rsyslogd
27015 root      20   0  143m  52m 3096 S  0.3  0.3   0:06.41 spamd
27016 root      20   0  143m  50m  684 S  0.0  0.3   0:00.03 spamd
27018 root      20   0  143m  50m  684 S  0.0  0.3   0:00.02 spamd
31024 user001   20   0  105m 1804 1448 S  0.0  0.0   0:00.01 bash
31162 user001   20   0  105m 1796 1448 S  0.0  0.0   0:00.01 bash
31385 user001   20   0  105m 1796 1448 S  0.0  0.0   0:00.02 bash
 1799 root      20   0 98.1m 1884 1092 S  0.0  0.0  13:52.34 miniserv.pl
 1963 root      20   0 97.9m 1244  788 S  0.0  0.0 188:02.58 snmpd

VIRT順にソートすると、こうなります。

以上、よろしくお願いします。

Answer 1

df するとどのような結果になるでしょうか？
tmpfs に巨大なファイルがあったりしないでしょうか？

---

/dev/shm になにか巨大なファイルがありませんか？
そこは tmpfs というメモリベースのファイルシステムみたいなものです。
それが原因でスワップを圧迫しているように思います。

Comments

[moriyama]

回答ありがとうございます。

dfは以下のような結果になります。

$ df
Filesystem 1K-ブロック 使用 使用可 使用% マウント位置
/dev/sda3 956426956 99536216 808307012 11% /
tmpfs 8221636 6185552 2036084 76% /dev/shm
/dev/sda1 247919 72690 162429 31% /boot

[ngyuki]

追記しました

[moriyama]

/dev/shmに6GB程度のファイルが存在しました。
これを/homeなりに移動すれば解消されるのでしょうか？

[ngyuki]

解消されるかどうかはやってみなければわかりませんが可能性は高いです。
また、そのファイルが何のために存在するのかわからないため、移動や削除することで新たな問題が発生しないかどうかもわかりません。

[moriyama]

配置されていたのが.gzファイルだったので、圧縮時の一時フォルダとして利用されていた可能性が高いのかなと思います。
他のシステムなどで読み込んでいなければ移動して大丈夫とみていい感じですかね。

そもそも、単純なWebサーバとしての利用以外の用途はないので、httpdの障害を誘発する可能性が低いと判断できれば、削除してみようかと思います。
ありがとうございます！

[ngyuki]

この件、ファイルを削除してみた結果、スワップの問題は解決されたでしょうか？

[moriyama]

ご連絡遅れましてすみません。
消すのにいろいろと手続きが必要で、遅れました。

削除してみた結果ですが、問題解決されました！
ありがとうございました！

Answer 2

まず、この状況ではなにも障害は出ていないと思います。Swap space の値は無視してください。
スラッシングが起きてはじめて問題になります。

Swap space が使われることは問題ありません。メモリの中で長い間使われていない領域が
Swap out されているだけです。
他のサーバーとの違いは、他のサーバーの動作しているプログラムはメモリを全体的に
平均的に使うのに対して、このサーバーはよく使う部分と、使わない部分がはっきり分かれているからです。
Java や Perl はコードがかなり多く、使われない部分も多く、負荷が低いということは使われない部分はほぼ使われないので、このようなことは起きうるでしょう。

もし、Swap space が使われるということが数値的に出ることが嫌ならば vm.swappiness を ０にするしかありません。

16GB に対して、4GB のSwap で、いびつでも何でもないです。問題ありません。

Comments

[eripong]

仰るとおりですね。
Webアクセス障害が起きているということで、
その原因は別途調査が必要そうですが、スワップが原因にはなりませんね。

[moriyama]

回答ありがとうございます。

なるほど、アクセス障害の原因は他にありそうということですね。
また、16GBに対して、4GBのSwapはいびつでないということもわかりました。

ただ、ApacheとMySQL以外の部分に関しては、共通なはずなので、JavaやPerlのコードが原因というのは少し疑問です。
現状、VPSを使用していて、コンテンツはHTML+PHPのみなので、JavaやPerlのコードはVPSにデフォルトでインストールされている管理ソフトか何かに使用されているものと思います。
他の同じVPSのサーバもJavaやPerlのコードが含まれているのにもかかわらず、発生しません。

Answer 3

RHEL 6 / CentOS 6 でしょうか？
6.4 の kernel-2.6.32-358.el6 にバグがあり、より多く swapout してしまうようです。
ディスクI/Oで高負荷になるなどの問題がなければ、そのままでいいのではないでしょうか。

https://access.redhat.com/solutions/33375

There is also a bug in version kernel-2.6.32-358.el6 (6.4), whereby the amount of swap
utilized increases dramatically over previous versions even though free still shows
substantial memory is still available. This is a private bugzilla at this time.

This issue is tracked via Red Hat Private Bug 949166 - Much increased swap usage, io
performance regression with -358 kernel. This bug is not publicly accessible. For more
information about this bug, please contact Red Hat Global Support Services.

This bug is not fixed in RHEL 6.5 and is still being worked.

Comments

[moriyama]

回答ありがとうございます。

他にも同一のOSを搭載したサーバを管理していますが、このような現象は起きていません。
動作するソフトウェアなどによる何かしらの条件があるのでしょうか…。

[TaichiYanagiya]

例えば、httpd へのアクセス数が多く、子プロセスを起動するためより多くのメモリを必要として、他のアイドルプロセスのメモリを swapout しているとか。

[moriyama]

アクセス数でいえば、確かに瞬発的に高負荷がかかることがあるサーバではあります。
バグとの兼ね合いで負荷がかかるたびにswapoutしてしまうといったかたちなのでしょうか……

ちなみに、他の同一の正常なサーバは、Webアプリを動作させていて、アクセス数は少ないですが、MySQLを動作させていたり、定期処理で重い動作をさせたりしているので、メモリ使用量の観点では、正常なサーバの方がメモリを使用しています。

[TaichiYanagiya]

正常なサーバの方がメモリを使用しているとのことですので、ちょっと原因がわかりません。

根拠に乏しい仮定ですが、
(1) 瞬発的にアクセスが増え httpd 子プロセスの実メモリ使用量が多くなる
(2) swapout が起きる
(3) httpd 子プロセスが MaxRequestsPerChild 設定値までリクエストを処理後、再起動し、現在の実メモリ使用量は少なくなっている

とか。
瞬発的にアクセスが増えたときの httpd の実メモリ使用量と Swap使用量の遷移を調べないとわかりませんが、もしそうだとすると、httpd.conf の MaxRequestsPerChild を小さくして、子プロセスの実メモリ使用量が多くなる前に再起動させてしまえば、緩和することができるかもしれません。

[moriyama]

ただ、もし現状のスワップ領域に空きがない状態で、瞬発的アクセスが再度あったとき、swapoutできずにメモリ使用量の多いプロセスがカーネルによってkillされないかが心配です。

とりあえず実メモリ容量が大きく、今のところ多数のアクセスにも耐えられてはいることから、実際の物理メモリ容量を超えてswapoutしたとは考えにくいですし、子プロセスの再起動でメモリを離さないのであれば、何かしらのメモリリークが原因の可能性もありますかね……

Answer 4

ここやここにあるようなコマンドで、スワップ領域を使用しているプロセスを絞り込めないでしょうか？

cat /proc/$$/smaps | grep -i swap | awk 'BEGIN{sum=0}{sum+=$2}END{print sum}' 

grep VmSwap /proc/*/status | sort -k 2 -r | head

Comments

[moriyama]

grep VmSwap /proc/*/status | sort -k 2 -r | head

を実行してみましたが、topコマンドのSwap降順ソート時と同様の結果になりました。

$ grep VmSwap /proc/*/status | sort -k 2 -r | head
/proc/1799/status:VmSwap: 19020 kB
/proc/19704/status:VmSwap: 3692 kB
/proc/1963/status:VmSwap: 3000 kB
/proc/1620/status:VmSwap: 2228 kB
/proc/1531/status:VmSwap: 916 kB
/proc/1708/status:VmSwap: 760 kB
/proc/1717/status:VmSwap: 748 kB
/proc/6006/status:VmSwap: 568 kB
/proc/1726/status:VmSwap: 552 kB
/proc/1608/status:VmSwap: 500 kB

[eripong]

なるほど。

NUMAアーキテクチャの影響でしょうか？
CPUのノード数はどうなっているでしょうか？
http://d.hatena.ne.jp/fat47/20121121/1353495937
にあるように、
# numactl --hardware
で確認してみてはいかがでしょうか？

また、スワップが0になることで、サーバ動作上の問題は、
発生しているでしょうか？

[moriyama]

回答ありがとうございます。

ノード数により不均一にメモリが割り当てられることがあるのですね。
勉強になりました。

ですが、今回のサーバはノード数が1なので、そのようなことはなさそうです。

$ numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3
node 0 size: 16359 MB
node 0 free: 10869 MB
node distances:
node 0
0: 10

サーバ動作上の問題についてですが、実は同一構成のサーバがもう1台あります。
そのサーバはこのようなスワップ領域を使い切る現象が起きていない状況です。

また、今回のこの問題のサーバは、何度かApacheの再起動で復旧するようなWebアクセス障害が発生しています。
正常なもう1台のサーバでは、このようなアクセス障害が起きていません。

正常なサーバの方ではMySQLも動作しています。
問題のサーバはMySQLを稼働させていません。

なぜ、問題のサーバだけが不安定なのか調査したところ、スワップ容量の空きがないのが原因では？との予測になり、とりあえず解消させて様子を見たいといったところです。

[eripong]

NUMAは関係なさそうですね。
Webアクセス障害が発生しているとなると、
放置できませんね。

# swapoff -a
# swapon -a
してみたら、どうでしょうか？

[eripong]

そういえば、スワップの空き容量の推移は、どの様になっているでしょうか？
徐々に増えるイメージですか？高負荷のタイミングと合いますか？
sarなど残っていませんか？

[eripong]

katsumiyさんの回答を踏まえて、
アクセス障害の原因を現在のスワップ容量が0であることから調査するのは、
(直接の原因の可能性が低いため)時間がかかりそうに思います。

アクセス障害が起きた時点、その前後の情報を元に調査を行う方が
早いように思います。
その方向の調査は実施されているでしょうか？

少し話題が違うので、別質問にした方が良いかも知れません。

[moriyama]

なるほどです。ありがとうございます。

実をいうと、私の方で完全に契約・管理・監視しているサーバではなくて、アクセス障害発生当時の情報がほとんど残っていなくて、とりあえずメモリを怪しんでいるという状況です。（sarや各種ログも時間がたちすぎて消失してます）

アクセス障害への対策に関してはとりあえず、障害が再発したときに、原因を追えるような環境を整えておくような方向で進めようかと思います。

Answer 5

apache の prefork で実行しているのでしょうか。

top コマンドを見ただけで、
java が 6G 程度、apache 1プロセスが 300M を超えていて、
約 20プロセス程度が稼働していますね。
java + apache で約 12GB 使用している計算になります。
（バッファが少ない感じ）

サーバの物理メモリ16GB、スワップ4GB なので、
apache プロセスが 26, 7 追加されると
スワップアウトになりそうです。

取り急ぎ、
httpd.conf で apache の子プロセスの上限を
正常サーバと問題サーバで比較されてはいかがでしょうか。

Comments

[moriyama]

回答ありがとうございます。

httpd.confの値は、正常サーバ、問題サーバ共に共通です。

<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>

Answer 6

スワップ領域を拡大できませんか？

ディスク上にスワップ領域を確保するのは、物理メモリの容量よりも大きなメモリ空間を使った処理を可能にするためです。
そのスワップ領域を使い切ってしまっているのですから、今の計算機の使われ方に対してスワップ領域が不足しているという事です。

解決作は２つあります。
１） 不要なプロセスを停止して、使用するメモリの量を減らす。
２） スワップ領域を拡大する。

私は、スワップ領域を拡大する方をお勧めします。

物理メモリの容量とスワップ領域の大きさの比率は、１：１．５～４程度にするのが普通です。
ところが、質問を見ると

         total

Mem: 16443276
Swap: 4095992

スワップ領域（４GB)が物理メモリ（１６GB)の４分の１しかないというのは、相当いびつです。
スワップ領域を３２GBに変更すれば、問題は解決すると思います。

Comments

[TaichiYanagiya]

多いにこしたことはありませんが、インストーラーが自動でサイズを決めてしまうのかもしれません。
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s2-diskpartrecommend-x86.html

[moriyama]

回答ありがとうございます。

他の管理しているサーバではこのようなスワップ領域を使い切る現象が起きていないので、単にこのままスワップ領域を拡大しても、また同様に、本来物理メモリに配置されるはずのデータがスワップ領域に不自然に流れてしまうのではないかといった懸念があります。

スワップ領域を広くすれば、使い切ることはなくなるかもしれませんが、やはり物理メモリに余裕があるのに大量にスワップ領域を消費するという現象には疑問が残ります。