質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

89.13%

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

解決済

回答 6

投稿 編集

  • 評価
  • クリップ 8
  • VIEW 28K+

moriyama

score 251

お世話になります。

現在、稼働中の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順にソートすると、こうなります。

以上、よろしくお願いします。
  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 6

+7

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/07/08 21:24 編集

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

    キャンセル

  • 2015/07/09 10:24

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

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

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

    キャンセル

checkベストアンサー

+6

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


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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/07/09 12:38

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

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

    キャンセル

  • 2015/07/09 16:49

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

    キャンセル

  • 2015/07/14 18:37

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

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

    キャンセル

+4

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.

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/07/08 17:09

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

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

    キャンセル

  • 2015/07/08 17:42

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

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

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

    キャンセル

  • 2015/07/08 19:49

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

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

    キャンセル

+2

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/07/08 20:18 編集

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

    キャンセル

  • 2015/07/08 22:52 編集

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

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

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

    キャンセル

  • 2015/07/09 10:43

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

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

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

    キャンセル

0

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

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/07/09 10:28

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

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

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

    キャンセル

-3

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

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

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

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

物理メモリの容量とスワップ領域の大きさの比率は、1:1.5~4程度にするのが普通です。
ところが、質問を見ると
             total
Mem:      16443276
Swap:      4095992

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


投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/07/08 16:25 編集

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

    キャンセル

  • 2015/07/08 16:52 編集

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

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

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 89.13%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る