負荷とディスクブロック待機の突然のピーク

負荷とディスクブロック待機の突然のピーク

優秀なサーバーの達人の皆様、こんにちは!

私は、Apache Tomcat サービスと MySQL データベースをホストする Ubuntu サーバーを実行しています。サーバーの負荷は、週の最も忙しい時間帯でも常にゼロに近いです。それにもかかわらず、サーバー全体が応答しなくなるランダムなハングアップが週に 1 ~ 2 回発生します。

このロックダウンの興味深い効果は、すべての cronjobs が予定より遅れて実行されるように見えることです。少なくとも、さまざまなシステム ログのタイムスタンプはそれを示しています。したがって、Tomcat サービスの一部として実行されているカスタム ソフトウェアだけでなく、サーバー全体が実際にフリーズしているように見えます。ハングアップは通常 3 ~ 5 分ほど続き、その後はすべて正常に戻ります。

Hardware:
Model: Dell PowerEdge R720, 16 cores, 16 GB ram
HDD-configuration: Raid-1 (mirror)

Main services: 
apache tomcat, mysql, ssh/sftp

#uname -a
Linux es2 2.6.24-24-server #1 SMP Tue Jul 7 19:39:36 UTC 2009 x86_64 GNU/Linux

sysstat を実行すると、平均負荷とディスク ブロック待機の両方で大きなピークが見られます。これは、顧客がバックエンド システムに問題を報告した時刻と正確に一致しています。以下は、12:30 頃に非常に明らかなピークがある sar からのディスク使用量のグラフです。

これを外部サーバーに置いたことを心からお詫びします。しかし、私の評判が低すぎるため、ここにファイルを直接含めることができません。また、リンクを 1 つしか投稿できないため、それらをまとめて置く必要がありました :S

Sar プロット:http://213.115.101.5/abba/tmpdata/sardata_es.jpg

グラフ 1: ブロック待機。約 12.58 で使用率が 100% まで上昇することに注意してください。

グラフ 2: ブロック転送。ここでは異常はありません。

グラフ3: 平均負荷、ピーク、グラフ1

グラフ 4: CPU 使用率はまだ 0% に近い。

グラフ5: メモリ、特に異常はない

システムにこの影響をもたらす原因について、何か手がかりがある人はいませんか? 先ほど説明したように、サーバーで実行されている唯一のソフトウェアは、ユーザーがデータベースに接続できるようにするための SOAP インターフェイスを備えた Tomcat サーバーです。リモート アプリケーションも SSH 経由でサーバーに接続し、ファイルをプルしたりアップロードしたりします。忙しいときには、約 50 の同時 SSH/SFTP 接続があり、http (soap/tomcat) 経由の接続は 1 ~ 200 未満であると推測しています。

Google で検索してみると、ファイル ハンドルと inode ハンドルに関する議論が見つかりましたが、これらは 2.6.x カーネルでは普通のことだと思います。反対する人はいますか?

cat /proc/sys/fs/file-nr
1152    0       1588671
cat /proc/sys/fs/inode-state
11392   236     0       0       0       0       0

同時に、「sar -v」は上記のハングアップ時のこれらの値を表示しますが、ここでの inode-nr は上記と比較して常に非常に高くなります。

12:40:01    dentunusd   file-nr  inode-nr    pty-nr
12:40:01        40542      1024     15316         0
12:45:01        40568      1152     15349         0
12:50:01        40587       768     15365         0
12:55:01        40631      1024     15422         0
13:01:02        40648       896     15482         0
13:05:01        40595       768     15430         0
13:10:01        40637      1024     15465         0

私は、ハードウェア、OS、ソフトウェア、RAID 構成などの同じセットアップを実行している 2 台の独立したサーバーでこれを確認しました。したがって、これはハードウェアよりもソフトウェア/構成に依存していると信じたいと思います。

お時間をいただきありがとうございました
/Ebbe

答え1

この問題は、次のバグで報告されているように、Ubuntu 8.04 LTS (Hardy) と Dell PERC 6/i RAID コントローラ間の非互換性の問題に関連していました。参考: Ubuntu 10.04 LTS Lucid (カーネル 2.6.32) にアップグレードすると、問題は解決します。

他の誰かが同じ問題に遭遇した場合に備えて。

答え2

おそらく、テーブル全体をスキャンする重いクエリを実行しているのでしょう。遅いクエリのログを確認しましたか。

その場合は、適切なインデックスを追加するだけです。

PS: すでに実行済みの場合は申し訳ありません。

関連情報