ディスク待ち時間の短縮方法

[S_Kaw]

sar -d でavwait(ディスク待ち時間)とavserv(ディスク転送時間)を

比較したとき、

通常はavwaitがavservより低いのですが、

時々、avwaitがavservの3〜4倍になるときがあります。

（ディスク待ちが発生している）

しかし、sar -d の%busyは通常時とさほど変化がありません。

（ほぼ10以下となっています。）

もっとディスク待ちを処理して

ディスクI/Oが発生しても（%busyが高くなっても）

おかしくないのではと考えているのですが、

ディスク待ち時間を短縮することはできないのでしょうか？

なお、CPU使用率は高くありませんし、

(sar -u の%sys=5程度,%usr=10程度,%wio=1程度）

メモリ空き容量も十分あります。

（vmstatのfree=350000〜400000(1.3GB〜1.5GB)程度、実装メモリ4GB）

申し訳ありませんがご教示の程お願いします。

[oops]

待ち時間を短縮することは無理でしょう。なぜ avwait が長くなってるか(キューが長くなっているか)を考えた方が良いと思います。

多重度が高いことによりキューが長くなっているのであれば、並列に処理できる数(タグの数)を大きくすることで対応できるかもしれません。確かデフォルトでは8で、scsi_cntl(1M) で LUN ごとに変更できたと思います。

ただ、ホスト側のタグの数をあげた場合、今度はデバイス側のキューがフルになって性能低下を招く場合もあります。デバイス側のキューサイズや LUN 数から、ホスト側で最適なタグ数を算出してから変更した方が良いと思います。

また、sar の不具合(仕様？)で avwait が実際より大きくでるというのを聞いたことがありますので、sar のパッチを最新にするという対応でも効果があるかもしれません。

[S_Kaw]

oops様、貴重な情報ありがとうございます。

scsictl(1M)コマンドでqueue_depthを変更することにより、

SCSIデバイスのキューの深さをデバイスごとに調整するということですね。

http://docs.hp.com/ja/4369/KCparam.SCSImaxQueue.html

http://docs.hp.com/ja/B2355-60104-04/scsictl.1M.html

http://docs.hp.com/ja/B2355-60104-09/scsi_max_qdepth.5.html

最後のURLには

「このパラメータは経験豊富なシステム管理者のみが変更するようにし、

　また値の変更は慎重に行ってください。」

との記載があるため、変更するかどうか迷っています。

もし変更した経験がありましたら、変更時の考え方やポイント・注意点

などご教示頂けないでしょうか。

また、avwaitが長いときは%wcacheが60を下回っていましたので、

バッファキャッシュサイズの縮小も検討してみます。

sar の不具合に関しても情報提供ありがとうございます。

パッチを検索したところ、11.11で以下のパッチが見つかりました。

PHKL_29047: s700_800 11.11 SCSI IO Cumulative Patch

http://www2.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHKL_29047&context=hpux:800:11:11

内容としては、以下のような意味でした。

　SCSIでQUEUE FULLになったとき、自動的にキューの長さを減らす機構が働くが、

　キューの長さが１以下になったら、タグなしキューイングモードに変更される。

　その後、QUEUE FULL状態がなくなってもタグ付きキューイングモードに

　戻らないため、sarのavwaitとavqueの値が高いままというバグ

当方では、11.23を使用しており、avwaitとavqueの値も

高いままではなく元に戻りますので、sarの不具合ではなさそうです。

[oops]

返信が遅くなってすみません。

> scsictl(1M)コマンドでqueue_depthを変更することにより、

> SCSIデバイスのキューの深さをデバイスごとに調整するということですね。

その通りです。

> もし変更した経験がありましたら、変更時の考え方やポイント・注意点

> などご教示頂けないでしょうか。

先にも書きましたが、デバイス側のキューサイズが重要になります。いくらホスト側のタグ数をあげても、デバイス側が大きなタグキューをもっていなければ、デバイスが QUEUE FULL を返してきますので、結局ホスト側はタグなしIOを強いられることになります。

ディスクアレイの場合、LUNごとではなくて、コントローラでキューサイズが決まってたり、キューサイズを変更できたりします。デバイス側のキューサイズを考慮した上でホスト側のキューサイズをコントロールする必要があります。

例えば、アレイのタグキューサイズが LUN の数によらず 75 で、LUN を 10 個作っている場合を考えます。単純に考えると LUN ごとのタグキューは 7.5 になりますので、ホスト側のタグキューサイズをデフォルトの 8 より大きくすべきではありません。

> また、avwaitが長いときは%wcacheが60を下回っていましたので、

> バッファキャッシュサイズの縮小も検討してみます。

うーん、ここはちょっとよくわからないです。

ファイルシステム経由の書き込みを抑制したいから縮小ということですか？

> パッチを検索したところ、11.11で以下のパッチが見> つかりました。

このパッチは SCSI ドライバのパッチで、sar の不具合ではないです。タグなしIOのままであれば、avwait や avserv が sar で大きく表示されてしまうのは正しいです。私が言ってたパッチはこれでした。

PHKL_30515: s700_800 11.11 'sar -d' reports inaccurate data (最新は PHKL_33858)

ただ、11.23 ということなので、かわさんには該当しないですね。

[S_Kaw]

oops様、ご返信頂きありがとうございます。

ディスクアレイのタグキューの考え方は参考になります。

> また、avwaitが長いときは%wcacheが60を下回っていましたので、

> バッファキャッシュサイズの縮小も検討してみます。

この記述は、以下のHP-UX技術情報ベースを見て記載しました。

パフォーマンスチューニングの概要

ドキュメントID: UPERFKBAN00000726

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=ja_JP&docId=200000077040187

　ディスクI/Oの改善方法

　5. (%wcacheが90未満の場合は)バッファキャッシュのサイズを縮小します。

パフォーマンスチューニングを考える上で、バッファキャッシュを増やすのが

普通だと思っていましたので、私も少し引っかかっています。

もしよろしければ、この内容に関してご意見を頂けると幸いです。

P.S.

パッチ番号の情報ありがとうございました。

こちらでうまく探せず、お手数おかけしました。

[oops]

またまた返信が遅くなってすみません。

> パフォーマンスチューニングを考える上で、バッファキャッシュを増やすのが

> 普通だと思っていましたので、私も少し引っかかっています。

これ、パーセントの記載は間違ってませんかね？wcacheが90%以上ってちょっと考え難いです。write は必ず物理IOが発生しますし、読み込んで書くというものでもなく、syslog のようにログの追加のような動作をする(バッファの新規アロケートになる)ものが多いので、ヒット率が低くなるのはある意味当然で、60% くらいというのは普通だと思います。

確かに rcache が 70% くらいを定常的にきってくると、read の性能がボトルネックになるでしょうが。

ただ、書き込みが多い時に、バッファキャッシュを小さくするというのは効果があります。書き込みは内容を改変するので、かならず物理IOが発生します。したがって、ファイルシステム経由の書き込みが多い場合、キャッシュが大きいとキャッシュへの書き込みがどんどん行われてしまい、syncer がフラッシュする際に多量の物理IOが発生することで性能が落てしまうことがありました。最近はディスクが速いし、syncer の実装も変わってきたので、こういった書き込み性能問題はあまりないでしょうが、昔のシステムのようにディスクが遅い場合は特に、物理ディスクに対する書き込みをを抑制するために、キャッシュを小さくすることにより書き込みを絞る(write throttle)というチューニング方法をとることがありました。

[S_Kaw]

oops様、度々の質問にご返信頂きありがとうございます。

> 60% くらいというのは普通だと思います。

貴重なご意見ありがとうございます。

バッファキャッシュの見直し以前に、oops様が最初の返信でご指摘頂いた

「なぜ avwait が長くなってるか(キューが長くなっているか)」を調査してみます。

> 昔のシステムのようにディスクが遅い場合は特に、物理ディスクに対する書き込みを

> 抑制するために、キャッシュを小さくすることにより書き込みを絞る(write throttle)

> というチューニング方法をとることがありました。

HP-UX技術情報ベースに、VxFS ですがwrite throttle の記述がありました。

HP-UX 11i にupgrade 後、write performance が悪い。

ドキュメントID: jnav003761

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=ja_JP&docId=200000081011333

「システムが巨大なメモリと遅いストレージ装置の組み合わせになっていないかぎり

　write_throttle の値を変更しないことをお勧めします。」

といった記述もありましたので、まずは、ディスクアクセスしているプロセスや

ファイル等を特定し、原因を確認してみます。

本当にありがとうございました。

[oops]

> 「なぜ avwait が長くなってるか(キューが長くなっているか)」を調査してみます。

そうですね。

avserv も長くなってないようなので、ディスクの応答性に問題がある訳ではないと思います。

特に性能が悪くなっていないのであれば、そんなに気にされる必要もない気がしますが。

HP-UX技術情報ベースにある write throttle は、VxFS がもってる機能の方ですね。考え方としてはバッファキャッシュを減らすのと同じ考え方で、ディスクへのフラッシュを減少させるために存在します。