10046 trace name context forever

Unbreakable Enterprise KernelにUpgradeして気づいたのですがkernelのI/Oスケジューラが変更されていますね。 Upgrade前(OEL5.5)ではないのですが、多分5.3? 5.4?の時のI/Oスケジューラは以下でした。 [oracle@kshinkub ~]# uname -a Linux kshinkub 2.6.18-164.el5 #1 SMP Fri Sep 17 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [oracle@kshinkub ~]# cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq] Upgrade後は以下のようになっていました。 [oracle@kshinkub ~]$ uname -a Linux kshinkub 2.6.32-100.0.19.el5 #1 SMP Fri Sep 17 17:51:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [oracle@kshinkub ~]$ cat /sys/block/sda/queue/scheduler noop anticipatory [deadline] cfq 確か、deadlineはDBMSなどに向くと聞いたような気がするが。ちょっと時間のある時に調べることにする

小幡さん、yohei-aさん、wmo6hashさんなど、いろいろご意見がありましたが、一度、Oracleの非同期I/Oの実装はどうだったのか再確認が必要だと思いちょっと調べてみます。 手当たり次第やってもしょうがないので、以下の3つの観点で調査してみます。多分、何回かに分けて調査すると思うのですが、今回は初期化パラメータfilesystemio_options = [none|directio|asynch|setall]でどのようにI/Oに関するシステムコールが変化するか見てみます。 1. データファイルへの書き込み     これは、DBWRが行っていますので、filesystemio_optionsの各モードでDBWRがopen|writeを     どのように実行しているか? 2.REDOへの書き込み     これは、LGWRが行っていますので、filesystemio_optionsの各モードでLGWRがopen|writeを     どのように実行しているか? 3. データファイルの読み込み     これは、shadowプロセスが行っていますので、filesystemio_optionsの各モードでshadowプロセス     がopen|writeをどのように実行しているか? 1、2のトレースを取るには以下のような感じです。 # openのシステムコールを確認 strace -f -o /tmp/oracle.trc -e open sqlplus / as sysdba << EOF startup EOF # 別ターミナルで strace -o /tmp/oracle_dbwr.trc -p strace -o /tmp/oracle_lgw.trc -p # 別ターミナルで sqlplus xxx/yyyy SQL> insert into xxxx values (xxxx); SQL> -- lgwに書き出させる SQL> commit; SQL> -- dbwの書き出させる SQL> alter...

先日 、Smart Flash Cacheを実行した際に2回目が必ず遅いと書きましたが、あれから、ちょっと調べてみました。原因は単純なのですが。一応、ご報告です。 先日のテストを再度実行し、その時のv$sysstatのflash cache 周りの統計情報を見てみます。 flash cache insert skip: DBWR overloaded physical read flash cache hits flash cache inserts flash cache insert skip: exists 1回目 147593 2 206803 398 2回目 0 207038 147880 206680 3回目 0 354529 90 354406 正直、上記のイベントに関してキチンとしたドキュメントが存在しないので、想像の域を超えませんが、 前回 、x$bhから、対象セグメントのサイズの全てが、flash cache上に乗っていないと言いました。その原因が示されているようです。 それは、flash cache insert skip: DBWR overloadedだったから。というわけでしょう。DBWRが忙しすぎると、flash cacheに乗せる(というよりもきっとflash cache上に存在するのか?flash cache上に空きがあるのか?といった管理)作業をスキップするようです。結果として、flash cache上に全データが乗っていなかったと(ある意味)納得がいきました。 もう少し、見てみます。 1回目は、基本的にデータファイルから、buffer cache(このテストでは小さくしてあるので、ほぼ、flash cache)に乗せる作業となります。なので、flash cacheのデータにヒット(physical read flash cache hits)することは無く、また、flash cacheにはデータが存在しないので、既存データとしてスキップする(flash cache insert skip: exists)ことなく、全て、flash cacheにデータを乗せています(flash cache inserts)。ただし、DBWRが忙しかったので、一部の...

そろそろ、Smart Flash Cacheのテストに戻ります。 基本的に、Smart Flash CacheはOLTP系で使うものだ。と 先日 書きました。しかし、テストでOLTP系のSQL(要はindex scan)を実行したら、なかなかbuffer cacheも汚れませんし、当然、flash cacheもキレイなままです。なので、通常はdirect path readを使ってしまうfull scanをscattered readに変える 裏技 を使って、一気に、buffer cacheを使いまくってみます。 そうすると、一つ、不思議な現象が起こっています。 "2回目のアクセスが、遅い" ORDER_ITEMS表をfull scan(db file scattered read)させた際の経過時間を示してみます。 当然、1回目のアクセスはディスクから物理読み込みが発生しているので、遅いのは当たり前です。しかし、2回目のアクセスはbuffer cacheもしくは、flash cacheに乗っているはずなので、速い。ということを期待していたのですが。。。1回目のアクセスよりも遅くなってしまっています。 ちなみに3回目以降は、想定通りのスピードです。 何故なのだ!? 理由を考える前に、そもそも、flash cacheにちゃんとデータが乗っているのか?を見てみる。 ORDER_ITEMSのセグメントサイズは3840MBでした。これが、全部buffer cache(+flash cache)に乗っているのかを確認してみます。 以下のSQLでx$bhからサイズを確認します。 /* block sizeは8KB */ select decode(state, 0, 'free', 1, 'xcur', 2, 'scur', 3, 'cr', 4, 'read', 5, 'mrec', 6, 'irec', 7, 'write', 8, 'pi', 9, 'memory', 10, 'mwrite', 11, 'do...

昨日 に続き、もう少しUnbreakable Enterprise Kernelをテストしてみます。kernelのupdateでちょっとビックリしたのは以下の問題です。 kernel アップデート後、再起動を行うと、起動はしているようだがコンソールが表示されない(udevサービス起動で固まっている) 回避策)   /etc/grub.confの起動オプションにnomodesetを追加する。   kernel /vmlinuz-2.6.32-100.0.19.el5 ro root=LABEL=/ rhgb quiet nomodeset で、 昨日のSSDでのOLTPベンチマーク をUnbreakable Enterprise Kernelで実行してみます。 結果は以下。 Redhat Compatible Kernel) 平均のTPMで17822、最高のTPMで20062、レスポンスタイムは12ms Unbreakable Enterprise Kernel) 平均のTPMで20411、最高のTPMで22966、レスポンスタイムは8ms 一応、ASH Viewerの結果) TPMはDBのリソース(AAS)が余っているので、参考程度なのですが、レスポンスタイムが12(ms) -> 8(ms)と 約33.3% のパフォーマンスアップとなっています。 レスポンスタイムは(当然ですが)I/Oレイテンシーだけで決定するわけではないので、33.3%のパフォーマンスアップという結果は、Oracleが言っている75%のI/Oパフォーマンスアップという謳い文句が大きくハズレていないことを示しているようです。 * ただし、これは再検証をしっかり行ったものではありません。参考程度にしてください... 参考ついでに、HDDも同様にベンチマーク結果を示しておきます。 ベンチマーク結果) ASH Viewerの結果) Redhat Compatible Kernel) 平均のTPMが4692で、最高のTPMでも6696、レスポンスタイムは159 Unbreakable Enterprise Kernel) 平均のTPMが5363で、最高のTPM...

海の向こうでOOWが賑やかに開催されていますが、Oracle LinuxでSSDを使った検証している自分にちょっとタイムリーな情報が入ってきました。Oracleが、良くも悪くもOracleデータベースに向けてカリカリにチューニングしたLinux Kernelを発表しました。それが Unbreakable Enterprise Kernel です。 Delivers Better than 75 Percent Performance Gain Over Red Hat Enterprise Linux 5 Compatible Kernel これは、ちょっと聞き捨てなりませんよね。詳細は、Oracleの発表資料を見て欲しいのですが、SSDに対するチューニングも施されているようです。 このkernelは、Oracleのサポート契約無しで、public yum リポジトリからインストールできます。詳細は、 こちら で詳しく説明されています。 時間のある時に、きちんと検証してみたいと思います。 * カーネルを 一気に 現在のメイン ラインに近いところまで持ってくる思い切りの良さは、個人的には嫌いではないです。

前回、HDDを使ったOLTPとHDD + SSD(Smart Flash Cache)のパフォーマンス比較を行ないましたが、せっかくなので、SSDにデータを配置した場合のパフォーマンスも計測してみます。 結果は、当然ながら最速となりました。 ベンチマークの結果) 平均のTPMで17822、最高のTPMで20062を記録しました。 ASH Viewerで確認) まず目を引くのはAASの値の低さです。まだまだ、余裕です。今回は、 前回 と条件を合わすため、15セッションでベンチマークを行っていますが、全く余裕でした。 一応、前回同様にUser I/Oの待機イベントの出しておきます。 ここまでのパフォーマンス結果をまとめてみます。ただ、SSDを使用した場合はパフォーマンス限界まで達していないので、ベンチマークでの平均レスポンスタイムを示しておきます。

Smart Flash Cache自体、現在のBuffer Cacheの代替キャッシュ(L2 キャッシュ)という位置づけでしかないが、使い道はそれなりに多い。メインメモリ(DDR3)4GBが10000円前後であるのに比べ、SSD 64GBは15000円前後です。SSDは、Buffer Cacheの不足を補うには、もってこいのデバイスと言えるでしょう。 ただし、これは、" あくまでもOLTP系の処理 "に限定したものです。OLTP系の処理では、インデックスを使用したアクセスが前提です。またインデックスアクセスは、基本的にバッファ上に存在する(してほしい)事も前提です。DWHのようなシステムでは、バッファ上に乗り切らないので、バッファを迂回したdirect path readを使用します。(が、これもin memory parallel Queryの登場で変わってくるかも知れません) あと、OLTP系のシステムで、SQL文がそれなりにチューニングされている場合、全体のスループットを上げる方法として、メモリを大容量にする。か、ちょろちょろ発生するディスクアクセスを超高速にする。しかありません。実際、現在のディスクで最速なものはSSDとなるわけですが、SSDへデータを移動するには通常のデータ移行にみられるような、システムの停止を含む業務への影響や、データ移行に伴う様々のリスクが存在します。 Smart Flash Cacheは、WindowsのReady Boostなみに簡単にパフォーマンスアップが望めます。それもリスクなしで。SSD 64GB程度を15000円程度で購入し、デバイスごとOracleに認識させるだけです。本当にそれだけです。(といっても、街の電気屋さんで買って、すぐに商用環境にくっつけるには勇気がいるでしょうが...) では、再度、Smart Flash Cacheのパフォーマンス比較をしてみましょう。 環境) memory_target = 4.5GB swingbenchにてTPC-Cベースの負荷を掛けます(swingbench用スキーマは約30GB程度です) セッション数は15 1) 普通にベンチマークを実施 ベンチマークの結果) 平均のTPMが4692で、最高のTPMでも6696に留まっています...

SSDも新しくなったことで、快調に検証が進みそうです。 まず、Smart Flash Cache単体のパフォーマンスを比較するため、以下の3パターンのパフォーマンスを測定してみます。 1) 大きなテーブルをdirect path readで検索する 2) 大きなテーブルをdb file scattered readで検索する 3) 大きなテーブルをdb flash cache multiblock physical readで検索する 3)は見慣れないイベントですが、基本的には、全て同じテーブル(大きなテーブル)に対して 1) バッファーキャッシュを迂回してディスクを直接読み込む 2) バッファーキャッシュを経由してディスクを間接的に読み込む 3) バッファーキャッシュ+フラッシュキャッシュを経由して、ディスクを間接的に読み込む ただし、今回のテストは、Smart Flash Cacheのパフォーマンスチェックなので、以下の条件を付けました。 * ご存知の方も多いと思いますが、11gR2から、通常のフルスキャン    (今ままでのdb file scattered read)は、ある条件によりdirect path readに置き換えられます。     これは、バッファーの再利用性が低いSQLだと(ある意味Oracleが勝手に)判断できる場合は、     バッファー経由のI/Oを諦めてディスクと直接I/Oすることを意味します * 今回のテストでは、db file scattered read と direct path readを使い分けたかったので、    非公開のパラメータ"_very_large_object_threshold"を変えています。 * "_very_large_object_threshold"の単位は多分MBだと思いますが、このサイズを超える場合、    大きいオブジェクトだと判断してdirect path readを選択するようです。なので、この値を非常に    大きくすると、今ままで通り、db file scattered readを選択する可能性が高いとい...

先日 、Smart Flash Cacheのテストを行うようテスト環境をセットアップしたのですが、その前からテストで使用する SSDの調子が悪い ことも書いていました。とりあえず、そのままの状態で、Smart Flash Cacheをテストしてみます。まず、テストを始める前に、Smart Flash Cacheが有効になっているか、軽く確認してみることにします。 簡単なSQLを実行して、パフォーマンスを比較、(そもそもエラーにならないか確認)してみます。 set timing on select * from soe.order_items; 細かいテストは次回以降で見ていくとして、ざっくりエラーは発生しません。しかし、パフォーマンスが尋常ではないくらい悪い。何かあるはずだと、アラートログを確認してみます。 ORA-27072: File I/O error Linux-x86_64 Error: 5: Input/output error Additional information: 4 Additional information: 1287652 Additional information: -1 flash cacheへのアクセスに失敗したので、Smart Flash Cache機能を無効にして、通常のBuffer Cacheのみの動作をしているようです。なので、かなり、パフォーマンスが悪化していたのだと思います。 このままでは、どうにもならないので、新たにSSDを調達しました。 今回、調達したSSDは CFDのCSSD-S6M64NMQ にしました。 前回、使用していたreal SSDと同じものですが、128GBを64GBにして構成しています。 とりあえず、これで、テストに支障はないようです。次からしっかりテストします。

1年くらい前に、オラクルOTNでセミナーを行う機会があり、そのセミナーの内容が OTNに公開 されています。その時に使用した資料をブログにも公開しておきたいと思います。 (1年前の古い資料をいまさら公開するな。と言われそうですが。。。) 確か、当時は、いろいろなセミナー(Oracleだけではなく)で話しをさせてもらう機会も多く、久しぶりのOracleに関するセミナーだったので話していて(個人的には)楽しかった気がします。チューニングの話しになると、とかく細かい話しになりがち(しがち)ですが、そうではない概念的な話しも何かのお役に立つかも知れません。 どうもIEだと上手くPDFが見えないことがあるみたいです。firefoxならちゃんと見えています。(どうなっているの??)

小幡さんよりSSDを使ったSmart Flash Cacheのテストについてコメントをもらったので、テストをしてみる予定です。 OEL(Oracle Enterprise Linux)でSmart Flash Cacheを使用できるようにするには、ひとつパッチが必要になります。 Patch 8974084 META BUG FOR FLASH CACHE 11.2PL BUGS TO BACKPORT TO 11.2.0.1 OEL では軽く手順を示しておきます。 1. 上記のOracleの個別パッチをopatchで適用します 2. 初期化パラメータ db_flash_cache_fileを設定します 3. 初期化パラメータ db_flash_cache_sizeを設定します 4. DBの再起動 ここで、ひとつ注意が必要です。通常、SSDを使用する場合、/dev/sd*のようなデバイスをdb_flash_cache_fileに設定すると思いますが、このようなデバイスファイルには、ORACLEインストールユーザーへ直接、読み書き権限がついていません。 今回、私の検証環境では、SSDは/dev/sdcでした。 $ ls -l /dev/sdc brw-r----- 1 root disk 8, 32 9月 14 01:58 /dev/sdc この状態で、Oracleを起動すると Errors in file /home/oracle/app/oracle/diag/rdbms/ora1120/ora1120/trace/ora1120_dbw0_23097.trc: ORA-27041: unable to open file Linux-x86_64 Error: 13: Permission denied Additional information: 1 DBW0 (ospid: 23097): terminating the instance due to error 27041 Instance terminated by DBW0, pid = 23097 のように、Permission deniedでDBWRが停止して、インスタンスも停止します。 そこで、/dev/sdcに権限をつけてあげるわけで...

Linuxでは多くのファイルシステムがあり、現在も様々なものが開発中です。 メジャーなものとしてext2、ext3がありますが、現在ext4が主流になろうとしています。また、oracleが開発した Btrfs(B-tree file system) などのような、SSDへの最適化やCOW(Copy on Write)など次世代のファイルシステムが沢山あります。 そこで、あまり最新のものは今後やるとして、昔からあるファイルシステムと今のファイルシステムでどの程度パフォーマンスに差があるのか検証してみます。 * 本当はBtrfsも検証したかったのですが、SSDが不調なのとDIRECT I/Oが未サポートだったので断念しました Linux 2.6.35 released, with Btrfs Direct I/O support and -ENOSPC handling of volume management operations, completing the -ENOSPC support. ext2からext3がLinuxの主流になったとき、ext3のジャーナリング機能を嫌い、Oracle構築でxfsを使う方も多かったのではないでしょうか?何せ、xfsはメタデータのみジャーナリングを行い、実データに関しては基本知らんぷりという仕様だからです。そんな中途半端?なジャーナリングを備えたファイルシステムがなぜ、好まれるのか? 答えは簡単です。Oracleにとって実データのジャーナルは必要ないからです。OracleはデータベースのファイルをO_SYNCオプションを付けて、オープンします。それは、OSのファイルキャッシュが危ないことを知っているからです。Oracleが「書いた!」と思っても、実はファイルキャッシュにしか書かれておらず、実際のファイルには「書かれていない!」こともあり得るわけです。これを確実に「書いた!」もしくは「失敗した!」とするため(白黒はっきりさせるため)にO_SYNCオプションを付けてオープンしているわけです。 とりあえず、上記のように、ファイルシステムは沢山あって、ジャーナリングなど高機能を提供するものも多い。ただ、そのような高機能が不必要な場合もあるわけで、システムによって、特性を見極めてファイルシステムを選択する必要...

先日、 SSDで非同期I/Oって大丈夫か? と書きましたが、非同期I/Oが問題なのでなく、ディスク自体が問題になっているようでした。 最初は、ファイルシステムがオカシイのか?(実は、OEL(kernel:2.6.18)では、experimentalレベルのext4を使っていたので)と思ったのですが、そんなレベルではないようでした。 smartctlで、SSDの状態を見てみるとエラーを示す値が大きくなっていました。これでは、かなり不安定になるのもうなづけます。。。（実際には、OSをインストールしていたディスクも非常に不安定になっていました。こちらは、ディスクを買い替えました) ということで、SSDを使った検証は後回しにして、HDDベースで、検証を進めることにします。が、最初にファイルシステムを疑ったついでに、少しファイルシステムについても検証してみることにします。

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

昨日に引き続き、検証のための部品の説明です。 検証を行うにあたって、そのボトルネックの把握とチューニング作業は非常に大切な作業 です。別に検証といった限定的な話しでなくても普通に大切ですよね。 Oracleでボトルネックと言えばWait Eventを見ることになるわけですが、普通はActive Session History(ASH : v$active_session_history)を見ることになります。 ASH自体はSQL文で見れば良いのですが(Enterprise Managerという手もあります...) GUIでキレイに見たい。 ということで、自分は、ASH Viewerを使います。 ASH Viewer   Javaで書かれたASH viewerです。結構キレイに見えます。ASH Viewer自体の   ライセンスはGPLですが、実際ASHの参照にはOracleのライセンス制限が適用   されますので、商用で無邪気に使えませんのでご注意ください。 ざっとイメージはこんな感じです。 ASHって何だ?チューニングって何だ?的な話し もまとめてドキュメント化して共有したいと思ってます。 (どこかで) こんな感じで、そろそろ、検証やら、それにまつわる考察やらを書いていくことにします。