負荷平均のランダムなジャンプの原因を突き止めるにはどうすればよいでしょうか?

負荷平均のランダムなジャンプの原因を突き止めるにはどうすればよいでしょうか?

Debian GNU/Linux 専用ボックスの負荷平均に問題があります。2 台とも (2 台)、MySQL とカスタム ゲーム サーバー ソフトウェア (小規模な「MMORPG」(まったく大規模ではありません)) を実行しています。CPU 使用率とメモリ使用率は問題ありません。CPU 使用率は通常 5% 未満です。RAM 使用率は 80 - 90% 程度まで上がりますが、常に空き領域、キャッシュ領域、バッファ領域が多数あります。スワップ使用率は 0 です。

uptime、top、またはそれを表示するその他のコマンドを使用して負荷を監視しているときに、負荷がランダムに 4 またはそれ以上に跳ね上がります。これは明らかに問題です。特に、両方のボックスに「たった」 2 つのコアしかないことを考えるとなおさらです。負荷平均が魔法のように跳ね上がった後、負荷はスムーズに下がり始め、リソース使用量が本当に一時的に跳ね上がったことを示しています。CPU 使用率は、top を 1 秒間隔で約 15 分間じっと見ているときは常に 0 ~ 5%、最大 10% です。

htop、vmstat、dstat などのツールをいくつか試しましたが、効果はありませんでした。興味のある方のためにログを次に示します。

http://www.k-zodron.com/log.txt

最初の行で発生した現象を除けば、CPU 使用率はほとんど上昇せず、負荷は天文学的な数値に跳ね上がります。私はこの分野の超専門家ではありませんが、4KB をディスクに書き込むことは I/O ボトルネックになる可能性もなさそうです。

MySQL チューニング プライマー ツールも実行しましたが、すべて正常であると報告されています。

問題を追跡して解決する方法について何かアイデアはありますか? ありがとうございます!

編集

http://www.k-zodron.com/munin/

Munin の統計情報。約 5 ~ 10 分ごとに更新されます。

答え1

mysql が一時テーブルを使用している可能性はありますか? io stat に munin チャートを追加できますか? 提供されたログの io 数値は信じられないほど低いようです。

ワーキング セットはどのようなものですか。データはメモリ内に適切に収まっていますか (そう思われます)。SQL への書き込みを頻繁に行っていますか (ログから判断すると、まったく行っていません)。

同時リクエスト数(SQL またはカスタム サーバーへのリクエスト)が突然急増する可能性はありますか? cat /proc/net/ip_conntrack|wc -l は何と言っていますか? 負荷スパイク中に何が表示されますか?

MySQLをオンにできますかクエリのログ記録が遅い- たとえば、すべてが 1 秒または 2 秒以上ですか?

ディスクはサーバーに直接接続されていますか、それとも iscsi / nfs でしょうか? ディスクの健全性ステータス (スマート) / RAID ステータスを確認できますか? ドライブの 1 つが故障している可能性があります... または、オフピーク時に簡単な io ディスク ベンチマークを実行して、適切な読み取り/書き込み速度が得られるかどうかを確認できます。

あるいは、dmesg に何か醜いものが表示されるのでしょうか?

編集: netstat |wc -l が負荷と相関しているかどうかを確認します

ps axms|wc -l が負荷と相関しているかどうかを確認します

lsof |wc -l が負荷と相関しているかどうかを確認する

[できれば、チャートに載せるために小さな Munin プラグインをハックしてください]。

答え2

もっと多くのメトリックが必要です。私は Ganglia を使用して、CPU、メモリ、ネットワーク、ディスク I/O などの従来の値、http リクエスト、mysql クエリ、スロー クエリなどのサービス ベースのメトリック、およびゲームに接続しているユーザーの数や、アプリが重要な関数を呼び出す回数などのアプリケーション ベースのメトリックなど、さまざまな値を収集します。

その情報を分析し、負荷のピークと比較することで、システム内で何が起こっているかをより正確に把握できるようになります。

関連情報