SSDで非同期I/Oって大丈夫か?

TPC-Cベースのベンチマークを以下の条件の下、4回実施した

クライアントPCから100セッションでswingbenchを実行

A: HDDにベンチマーク用データを格納し、非同期I/Oをオフ(Oracleのデフォルト値)
B: SSDにベンチマーク用データを格納し、非同期I/Oをオフ(Oracleのデフォルト値)
C: HDDにベンチマーク用データを格納し、非同期I/Oをオン
D: SSDにベンチマーク用データを格納し、非同期I/Oをオン

その際の、swingbenchの結果を示してみる

HDDを使用したベンチマークでは、TPMの結果が非常に不安定であることが一目瞭然(A、C)。SSDを使用したベンチマークでは、それなりに安定しているものの(B、D)、非同期I/Oをオンにしたベンチマークが群を抜いてスコアが高く、安定性が高いことがわかる(D)。
 この、秘密は何なのか?

このベンチマークの際に取得しておいたASH viewerの結果も合わせて見てみようと思う。

まず、非同期I/Oを使用しないベンチマーク(A、B)では、断続的にcommit(詳細はlog file sync)の待機が発生している。また、同様にconfigration(詳細はfree buffer waitsとlog file switch(checkpoint incomplete))で待機している。log file syncはREDOへの負荷が高まっている。つまり、REDOへ書き出しているLGWRがスムーズに書き込めていないことを示してる。一般的にはREDOログが配置されているディスクが遅い場合や、頻繁なコミットによるshort I/Oが引き金になることが多い。

また、free buffer waitsは、必要なブロックをBuffer Cache上から検索するが、存在しない場合、ディスクから読み込んでBuffer Cache上に乗せる必要がでてくる。その際、Buffer上がダーティブロックで一杯だった場合、DBWRに一回、ディスクに書き込んでBuffer Cacheをキレイにしてくれ。とお願いする必要が出てくる。それを待っているのがfree buffer waitsで、log file switch(checkpoint incomplete)は読んで字の如しだが、REDOログをスイッチしようとしたが、次のREDOログのチェックポイントが完了していないので待機しているということ。両者に共通することは、free buffer waitsもlog file switch(checkpoint incomplete)もDBWRがスムーズなI/Oができずに、詰まっているために引き起こされている現象だということ。

ちょっと整理してみると、

1. どうも、LGWRはスムーズにI/Oが行えていない(log file syncで待機中)
2. どうも、DBWRもスムーズにI/Oが行えていない(free buffer waitsとlog file switch(checkpoint incomplete)で待機中)

ということで、書き込み要求をスムーズに処理させる(可能性のある)filesystemへの非同期I/Oを有効にしてみることにする。(Oracleのデフォルトでは使用されない)

SQL> alter system set filesytemio_options=asynch scope=spfile;

結果は、一目瞭然(C、D)、commit(log file sync)は無くなった。これにより、TPCベンチマークのスコアも高くなっている。

しかし、HDDを使用したベンチマークでは、LGWRがスムーズにI/Oできるようになった分、自分自身のI/O要求が高まり(User I/O(db file sequential read))更に、HDDの限界値を超えるI/Oは当然できないので、log switchの発生と共に、DBWRのI/Oが飽和状態になり、TPCのベンチマークも下降線を示している。

一方、SSDを使用したベンチマーク(D)では、I/Oに余裕があるため、LGWRとDBWRのI/Oスループット向上が、そのままTPCのスコア向上に寄与している。

しかし、このベンチマークを走らせるようにしてから、OS kernelがI/O関連のエラーを出力するようになっている。原因はSSDへの非同期I/Oのようだが。。。更には、filesystem全体が破壊されてしまっている。。。

確かにパフォーマンス向上が驚くほどだが、二度と起動しないようでは。。。

ということで、もう少し詳細に調べることにする。