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 incomple...