Windowsでは、データベースまたは他の低遅延アプリが存在するボリュームにIO関連の問題がある可能性があることを検証または確認するたびに、ディスク遅延をチェックします。
Windows Average Disk sec/Transferカウンター> 18-20msが一貫して表示される場合、炭鉱のカナリアが死んだばかりなので、さらに調査する必要があります。ドロップデッドシンプル。
私は今Linuxを見ていますが、同様の遅延ベースのメトリックは表示されません。私が行った簡単な調査は、私がしたくないかもしれないことを示しています...私はほとんどの人がこれを追跡する方法であるI/O待機への多くの参照を参照しています。
これに関して使用する大まかな経験則はありますか?たとえば、データベースのボリュームに悪いと思われるI/O待機はありますか?単純なiostatコマンドで、TOPを目視するだけでなく、全体的なディスクの状態をよく確認できますか?
どうもありがとう!
個人的にはiostat -xk 10
とawait
列を見てください。
これは、Windowsと実質的に同じ指標Average Disk sec/Transferであり、秒ではなくmsで表示されます。したがって、同様の経験則を適用できますが、これはあらゆる種類の事柄に依存します。私は通常、ユーザーが15ミリ秒と20ミリ秒で不平を言い始めるのは非常に悪いことに気づきます。
Ctrl + cを押して終了するか、表示する反復回数をcountパラメータで指定します。最初の反復で使用された時間サンプルが小さいため、最初の反復の結果は大きく歪んでいることに注意してください。
から man iostat
ページ
awaitサービス対象のデバイスに発行されたI/O要求の平均時間(ミリ秒単位)。これには、キュー内のリクエストによって費やされた時間と、それらのサービスに費やされた時間が含まれます。
編集:await
は、本番環境の負荷がかかっているディスクを監視して、スループットとiopsが需要に対応できるかどうかを確認するために使用する主なメトリックです。
%iowait統計は、CPUとディスクの使用量のバランスに関する詳細です。 both cpuおよびディスクアクティビティが高い場合、%iostatは予想より低くなります。一方、かなり低いディスク使用率レベルから始めて、CPUがアイドル状態の場合、%iostatは比較的高くなる可能性があります。待っていると言われていることは、塩の粒と一緒に取られる必要もある。大量のシーケンシャルな読み取り/書き込みが発生している場合は、数値が低い値にスキューされます。書き込まれているほとんどのチャンクはシーケンシャルデータであり、サービスされるため、これらの条件下では18〜20ミリ秒の経験則は役に立ちません。要求が処理されるシーケンスをディスクに選択させることによりスループットを最適化するためにディスクに組み込まれたNative-Command-Queuing(NCQ)システムにより、他のランダムioが待機している間、ディスクによって非常に迅速に。