web-dev-qa-db-ja.com

サーバーでキャッシュ使用率が高くなっている原因を見つけるにはどうすればよいですか？

毎週金曜日の22:00頃から、サーバーは大量のキャッシュの使用を開始し、約2時間後に停止します。下記のサボテングラフをご覧ください。

Memory Usage

https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py で大量のメモリを使用するハンティングプロセスを試しましたが、表示されるのは次のとおりです。

_...
438.0 MiB +   1.1 MiB = 439.1 MiB       XXXEngine XXX 961f4dbc-3b01-0000-0080-ff115176831d xxx
520.2 MiB +   1.7 MiB = 521.9 MiB       XXXEngine XXX f2ac330c-3a01-0000-0080-a2adb5561889 xxx
 10.4 GiB + 829.0 KiB =  10.4 GiB       Java -server -Xms1G -Xmx5G -Djava.net.preferIPv4Stack=true -cp ../lib/hazelcast-3.2.2.jar:../lib/xxx.cache.jar com.hazelcast.examples.StartServer (2)
---------------------------------
                         28.1 GiB
=================================
_

これは100Gのキャッシュに近いものではなく、LinuxがディスクI/Oのキャッシュにそれだけのメモリを使用している可能性があると考えていたため、atopを使用して測定しました。これは、atop -r atop-20140919-230002-062979000.bin -d -D (-c)を実行したときに得られるものです。

_  PID                                   TID                                   RDDSK                                  WRDSK                                  WCANCL                                   DSK                                 CMD       1/405
    1                                     -                                  907.9G                                  17.0T                                    2.8T                                   97%                                 init
 6513                                     -                                  175.1G                                  46.1G                                    5.9G                                    1%                                 crond
 8842                                     -                                      8K                                 110.3G                                    128K                                    1%                                 xxxzmuc0
 6296                                     -                                    6.5G                                  25.1G                                   15.9G                                    0%                                 sshd
 4463                                     -                                   4668K                                  23.2G                                      0K                                    0%                                 kjournald
19681                                     -                                   1835K                                  22.5G                                   22.4G                                    0%                                 xxxtroker
 4469                                     -                                   4728K                                  15.2G                                      0K                                    0%                                 kjournald
 4475                                     -                                   4716K                                  14.9G                                      0K                                    0%                                 kjournald
 2401                                     -                                    588K                                  11.4G                                      0K                                    0%                                 kjournald
 8652                                     -                                    7.0G                                   2.6G                                    1.3G                                    0%                                 k6gagent
26093                                     -                                    9.5G                                     0K                                      0K                                    0%                                 bpbkar
...
_

そしてatopオプション__-c_を付けます。

_  PID   TID S  DSK COMMAND-LINE (horizontal scroll with <- and -> keys)                                                                                                                                                                            1/405
    1     - S  97% init [3]
 6513     - S   1% crond
 8842     - S   1% xxzmuc0 -m XXX
 6296     - S   0% /usr/sbin/sshd
 4463     - S   0% kjournald
19681     - S   0% xxxtroker XXX
 4469     - S   0% kjournald
 4475     - S   0% kjournald
 2401     - S   0% kjournald
 8652     - S   0% /opt/IBM/ITM/lx8266/6g/bin/k6gagent
26093     - S   0% bpbkar -r 2678400 -ru root -dt 0 -to 0 -clnt ...
...
_

つまり、initが17テラバイトのデータをディスクに書き込んだことがわかります。しかし、私はこれを引き起こしている原因を見つける方法がわかりません。 Linuxはディスク操作を高速化するためにキャッシュを使用していますが、プロセスがそれを必要としているときにキャッシュを返し、キャッシュを使用してサーバーを強制終了することはできないと私は考えました。

「RedHatEnterprise Linux Serverリリース5.5（Tikanga）」Linux delirium 2.6.18-194.26.1.el5＃1 SMP Fri Oct 29 14:21:16 EDT 2010 x86_64 x86_64 x86_64 GNU/Linuxを使用しています。

何が悪いのかを見つけるために（次は）何をすべきですか？

linuxcachememory-usage
1
Tony Stark

Bpbkarもアクティブであることがわかります。そのプロセスを確認します。これはSymantecNetBackupの一部です。問題が発生したときにバックアップが実行されているかどうかを確認してください。それを無効にして、バックアップがスケジュールされていないときに問題が再び発生するかどうかを確認します。

Bpbkarが有罪のプロセスである場合は、完全なログオンを有効にして、この問題の原因を特定する必要があります。彼らは常に大きな問題のリストを解決するので、最新の更新がインストールされていることを確認してください。

1
dirk

Slabtopユーティリティを確認してください。また、その時間枠の前後にシステムでスケジュールされたI/O集約型のcronジョブではないことを確認しましたか（つまり、mlocate/updatedb ..）？

slabtop --sort=c
6
Alpha01