SunOS5.10システムの監視中に奇妙な動作が見つかりました。
- ディスク使用率が100%に近い。
- ディスク待ち時間は0,0%です。
このシステムの主な目的は、jvmでアプリケーションサーバーを実行することです。これは、サーバーが過負荷になってクライアント接続がランダムに拒否されたときに発生します。問題がIOに関連している場合、IOレイテンシはおそらく0.0%を超える必要があります。コンピュータに他のボトルネックは表示されません。 CPU、RAM、およびネットワークインターフェイスの使用率が5%未満です。ディスクが飽和すると、システムは毎秒約0.5MBのデータを書き込みますが、データはほとんど読みません。
リアルタイム監視のsarmon
ためにデータがダンプされます。iostat -x
出力iostat
例:
extended device statistics
device r/s w/s kr/s kw/s wait actv svc_t %w %b
sd0,a 0.0 0.4 0.0 6.2 0.0 0.0 11.5 0 0
sd0,b 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
sd0,c 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
sd0,f 0.0 0.2 0.0 1.6 0.0 0.0 13.9 0 0
sd0,g 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
sd0,h 0.0 111.6 0.0 519.9 0.0 1.0 8.9 0 94
統計はオペレーティングシステムレベルで実行されるため、測定は正確でなければなりません。アプリケーションレベルでディスク飽和度を確実に検出し、それに応じて負荷を軽減することは可能ですか?
このような場合、考えられるシナリオは何ですか?
また、ddを使用してディスクの書き込み速度をテストしましたが、結果は次のとおりです。
time sh -c "dd if=/dev/zero of=/tmp/output bs=512 count=2048k"
2097152+0 records in
2097152+0 records out
real 0m3.250s
user 0m0.627s
sys 0m2.622s
ベストアンサー1
4KBが少し以上のデータを毎秒約111回書き込むスレッドが一つあるようです。これは、ディスクを100%使用状態に保つのに十分です(111 iops * 9 msサービス時間=毎秒1秒サービス= 100%)。そのディスク(実際にはそのパーティション)にデータを書き込む他のプロセスがないため、キューは空であり、すべての要求はすぐに処理されます。
これにより、ワークロードに特別なものや奇妙なことはありません。ディスクがボトルネックを引き起こすことです。
パフォーマンスを向上させるために、より高速なディスクまたはSSDを選択したり、分散書き込み機能を備えたディスクアレイを使用したり、より大きなブロックを使用するようにアプリケーションを調整したり、キャッシュサイズを増やしたりできます。
あなたのdd
テストは意味がありません。ディスクのパフォーマンスを測定するのではなく、本質的にキャッシュのパフォーマンスを測定することです。特に、そのファイルシステムのデフォルト値である/tmp
仮想メモリでサポートされているSolarisではさらにそうです。tmpfs