続 filesystemio_optionsと非同期I/O

前回(filesystemio_optionsと非同期I/O)でfilesystemio_options=asynchの動作が非同期I/Oになっていないのではないか?と書きましたが、もう少し、状況証拠をとるためにTPCのベンチマークを取得しました。

filesystemio_options=noneの場合とasynchの場合でほぼ同一の結果となっており、ますます、filesystemio_options=asynchの動作の怪しさが増しています。

- filesystemio_options=none

swingbenchの結果

ASH Viewerの結果

commitクラスの待機イベント

- filesystemio_options=asynch

swingbenchの結果

ASH Viewerの結果

commitクラスの待機イベント

- filesystemio_options=setall

swingbenchの結果

ASH Viewerの結果

基本的に全てのケースでUser I/Oの待機イベントで待機しているのは変わりません。しかし、特徴的な待機イベントとしてCommitクラス(内容はlog file sync)があります。none と asynchの場合にのみ発生しています。

LGRWが log bufferからREDOログへ書き込んでいるのを待機しているわけですが、

OLTP系の処理であれば、commitはそれなりに頻繁に発行される + それなりに多くのセッションが同様の処理をする。という特徴を考えると、LGWRのアクティビティは高くなります。LGWRが同期I/Oをしている場合、commit I/Oの衝突により各セッションが待機するであろうことは想像に難くありません。

それが、none の場合(同期I/O)の場合とasynch(非同期I/Oのつもり)で、ほぼ同一のレスポンス時間、同一TPMかつ、待機イベントの傾向である。また、setall(DIRECTかつ非同期I/O)の場合で、レスポンス時間およびTPMが改善され、待機イベントにlog file syncが無いこと。

上記を考えると、やはり、filesystemio_options=asynchは、非同期I/Oでない気がしますね。。。