10046 trace name context forever

従来からフルスキャン(通常 db file scattered read)をバッファーキャッシュを迂回するdirect path readに変更する手法としていくつか手段がありました。 * 今回は、Parallel Queryは除外 1. "_serial_direct_read"を設定する SQL> alter session set "_serial_direct_read"=true; 2. event 10355を設定 $ oerr ora 10355 10355, 00000, "turn on direct read path for scans" // *Cause: // *Action:  enable direct async read for scans 11gR2からは、フルスキャンでdb file scattered readを使うのか、direct path readを使うのか、Oracleが自動で決定しているようです。 勝手に選択されるのも、時と場合によっては問題になる可能性があるので、その仕組みを少し調査してみます。 以下の隠しパラメータが影響して、I/Oの制御を行っているようです。 "_small_table_threshold" lower threshold level of table size for direct reads "_very_large_object_threshold" upper threshold level of object size for direct reads セグメントサイズ > 5 * "_small_table_threshold" * blocksizeの場合にdirect path readを選択するようになります。 ただし、これは、event 10949で制御が可能です。 $ oerr ora 10949 10949, 00000, "Disable autotune direct path read for full table scan" // *Cause: // *A...

今回は、SQLパフォーマンスワークショップの話しを少しだけ。 第2回 SQLパフォーマンスワークショップ エンバカデロ・テクノロジーズさんとインサイトテクノロジー共同開催でワークショップを行うことになりました。 このワークショップで何を話そうかなと今まさに考えているのですが、まずはパフォーマンスチューニングのベーシックな 部分をきちんとお話ししようかなと思っています。 あと、ケーススタディを多めにして、参加者の方が考えながら参加できる内容にしたいと思っています。是非とも参加して みてください。 1. ディスクI/O系の話 データベースのボトルネックになりやすいのはディスクI/Oです。 データベースのディスクI/Oにはいくつかの種類が存在します。それらを上手く制御することがチューニングとなります。 では、ディスクI/Oを上手く制御できているのか? いないのか? はどうやって判断するのか? 2. コンテンション系の話 多くのデータベースは多数のユーザーが同時利用することを前提に設計されているので、1つのリソースを多数で共有する ための排他制御が様々な場所に実装されています。 排他制御はデータベース・カーネル側で制御しているラッチや内部ロックとユーザー自身で制御するロック(いわゆる行ロック)などがあります。 この排他制御を上手く行わないと、スループットが上がらないわけです。 3. コンフィギュレーション系の話 さらに、データベースの基本設定(パラメータや物理設計)の良し悪しでも、パフォーマンスに影響があります。 さすがに全部話していると時間がない気がしますが、出来る限りギュッとまとめて話したいと思います。

Oracle EEのオプションで最も使うと思われるものがPartitioning Optionではないかと個人的に思っています。小幡さんのブログ( Storage Serverフィルタリング考察 )にてPartition Viewという懐かしいモノが紹介されていました。7.2で鳴り物入りと書かれていましたが、すぐにPartitioning Tableがリリースされて陽の目を見なかったですね。。。 しかし、Partition ViewにはPartitioning Tableにない素晴らしい点があります。それは、EEじゃなくても使える。頑張って作りこめばPartitioning Optionみたいに使える(これは利点なのか...?)ことです。 というわけで、一回、Partition Viewをまとめてみます。 * 個人的には、昔、この機能を使いこなそうとかなり苦労しました。 まず、大前提です。 基本的には、Partitioning Tableのように論理的に一つのテーブルとして扱えません(あくまでも1つのビューです) なので、グローバルインデックスや、カラムの追加/削除、パーティションの追加/削除といったことは透過的に実行できません。 さらに、DMLもビューに対して実行できません(union all viewなので) もう一度書きますが、あくまでもビューです。 では、普通のビューとどう違うのか? それは、たった1つなのですが、現在のPartitioning TableのようにPartition ViewへのQueryの実行計画をPartitionを考慮して立ててくれること。です。 事前に準備すべき事は以下となります。 各テーブルのPartition Keyとなるカラムにはチェック制約が必要 初期化パラメータ(partition_view_enabled)がTRUE(ただし、大昔から、このパラメータは無くなり_partition_view_enabledがデフォルトTRUEとなっていますので、余り気にしない) 1のチェック制約を見て、ナルホドと思いますね。単純というか何と言うか... では、一応、やってみます。 -- 通常のビュー用 -- 2010 Q1 create table t2010q1 (term ...

以前、Unbreakable Enterprise KernelのI/O schedulerがdeadlineに変更されたと ブログ に書きました。 また、SSDであればnoopの方が合っているかもしれないとコメントに書きました。 実際のところ、どうなのでしょうか? 検証してみます。 まずは、I/O schedulerを変更してみます。変更するには3通りあるのですが、 1. bootパラメータ(elevator)を変更する 2. /sys/block/<device>/queue/schedulerを直接変更する 3. udevのルールを変更する 今回は、検証なので、2の直接書き換え方式を使っていますが、通常はは、SSDのみをnoopとしたい、かつ、リブートで元に戻って欲しくない等になるので、3のudevルールで対応すると思います。 以下のudevのルールを/etc/udev/rule.dに作成します。 SUBSYSTEM=="block", SYSFS{queue/rotational}=="0", RUN+="/bin/sh -c 'echo noop > /sys$devpath/queue/scheduler'" * queue/rotationalは磁気ディスクであれば1が設定され、SSDであれば0が設定されますが、USBのような安価なフラッシュ   ディスクの場合は1が設定される場合があるようです 今回は、15セッションでTPC-Cのベンチマークを実施してみました。 1. deadline $ su - root -c "echo deadline > /sys/block/sdc/queue/scheduler" $ su - root -c "echo 3 > /proc/sys/vm/drop_caches" Unbreakable Enterprise KernelではデフォルトとなっているdeadlineI/Oスケジューラのパフォーマンスをチェックしておきます。 今回のテストの結果では、平均のレスポンスタイムが22msとなってい...

前回( 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...

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