10046 trace name context forever

前回( 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が無いこと。 上記を考えると、やはり、filesystemi...

先日、 filesystemio_options=asynchの場合のopenモードが不思議 と書いたのですが、一応、サンプルソースを使って試してみました。 サンプルソースはLinux Foundationにある aiocp を拝借してテストしました。 [oracle@kshinkub aio]$ wget http://devresources.linuxfoundation.org/daniel/AIO/aiocp.c --2010-10-02 21:45:34-- http://devresources.linuxfoundation.org/daniel/AIO/aiocp.c devresources.linuxfoundation.org をDNSに問いあわせています... 140.211.169.81 devresources.linuxfoundation.org|140.211.169.81|:80 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 11896 (12K) [text/x-csrc] `aiocp.c' に保存中 100%[==================================================================>] 11,896 37.3K/s 時間 0.3s 2010-10-02 18:45:35 (37.3 KB/s) - `aiocp.c' へ保存完了 [11896/11896] [oracle@kshinkub aio]$ gcc -laio -o aiocp aiocp.c 処理内容はざっと以下の通りです。 1. コピー元ファイルのopen 2. コピー先ファイルのopen 3. 1に対してreadを非同期I/Oで要求し、その完了をコールバック関数で待ち受ける 4. 3のread要求が完了した場合、コールバック関数が呼ばれ、さらに2に対して非同期でwrite要求が発行される 5. write要求も完了時にはコールバック関数が呼ばれる 6. 全てのread/writeの要求が発行された場合、その完了を待って終了 つまり、処理の重いwrit...

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