MySQL5.5を実行しているSolaris10x86_64システムがあります。使用時間が長い場合、データベースからの応答が非常に遅くなります。遅いクエリは数分になり、通常は1秒未満で返されます。 CPU使用率は60〜70%の範囲です。負荷平均は定期的に20代になり、まれに40代になりますが、私は50代まで見ました。 (ハイパースレッディングが有効になっている2つの4コアCPU。)ディスクの書き込みを待機しているように、I/Oの問題のように動作しますが、実際のI/Oの問題があることを示す兆候は見られません。平均ディスク待機時間は一貫して0であり、平均待機キューは0.2〜0.3の範囲であり、ディスクビジー率は時折15%の領域に忍び寄ります。 (これはすべて、sarによると。)
ストレージは、2つのSASドライブの5つのzdevミラーのzfszpoolです。インテントログデバイスはありませんが、このワークロードの問題とは見なされません。
何が足りないのですか?
よりSolarisに似た答えを提供したかった:
マルチプロセッサ/マルチコアボックスでは、CPU負荷をあまり使用できません。コアの1つがときどき完全に使用されるかどうかを確認する場合は、最初はmpstat
/prstat
ではなくtop
を使用します。
mpstat
に8行の出力がある場合、それは8つのCPUコアがあることを意味し、prstat
で12.5%を超えるCPUリソース(100/8)を消費しているプロセスはCPUである可能性がありますバウンド。これが本当にそうであるかどうかをテストするには、prstat -L -p <pid>
を使用して、そのプロセスの個々のスレッドが12.5%に達するかどうかを確認できます。これにより、プロセスがCPUにバインドされていることが確実にわかります。ボックスにはかなりの数の使用可能なCPUコアがありますが、単一の処理スレッドは1つのCPUコアにしか存在できないことを常に覚えておく必要があります。 MySQLがボックスを利用するためには、作業を複数のスレッドに分割することがどれほど優れているかが問題になります。 MySQLにホットスレッドが1つしかない場合、強力なマシンはあまり役に立ちません。
また、Linux/SolarisサーバーのワークロードでIntelハイパースレッディングをオフにすることをお勧めする人もかなりいます。これがないと、実際にはパフォーマンスが向上するからです。 YMMM。私が理解していることから、Intel HyperThreadingはデスクトップタイプのワークロードには優れていますが、1つのことだけを実行し、それを高速に実行することになっているサーバーでは、パフォーマンスに悪影響を与える可能性があります。
ここから行くことができるルートは少なくとも12あるので、事実を知る前にアドバイスするのは少し難しいです。
負荷の平均は通常20代、時には40代または50代であるとおっしゃっています。次に、16個の使用可能なプロセッサ((2cpus x 4コア)x 2)があるため、20代の平均負荷は、プロセスがCPU時間のために戦っていることを意味し、40代または50代では大量の待機があります。
CPU使用率とCPU負荷はそれほどうまくマッピングされていませんが、正しくスレッド化されていない限り、使用率は少し高くなると思います。
橋の交通のシナリオを使用して負荷平均をうまく説明する別の投稿があります:
つまり、完璧な世界では、負荷の平均がプロセッサの数(この場合は16)を超えることはありません。
これはおそらく、ZFSやMySQLの問題ではなく、システムに過大な負担がかかっている可能性があります。
**編集、CPU使用率が100%になっているというコメントが追加されたようです。これは、CPU時間を待っているだけのプロセスとも一致します。