
優秀なサーバーの達人の皆様、こんにちは!
私は、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: すでに実行済みの場合は申し訳ありません。