2011年4月11日月曜日

TPC-H USD/QphH を計算する

TPC-H検証の続き、ですが、
今後は QphHだけでなく、USD/QphHも出そうと思うので、今日はそのための準備。

値段の出し方は TPC BENCHMARK H Standard Specification の Clause 7: PRICING に定義されていますが、簡単に書くと
ハードウェアとソフトウェアの価格 + 3年間の保守(24x365)
が、システムの値段となります。

Oracleの価格を調べるなんて10年以上やってない。
今回のCPUは AMD Phenom II X6 1100T (3.3 GHz/6 core) なので、Core係数が0.5で 3CPU分。
これを Named User Plusライセンスで計算すると 813万(税込) !!! 年間サポートが 179万(税込) ! 3年分で 1,350万。 マジー！？ 12万のPCで動かすのにですよーー！
サポートフィーは更に値上げされるとかいう話も...

この計算合ってますか?
しかし、こんな高い製品をみんな良く買ってますね。ごめんなさい。世間知らずでした。

これに HW価格 12万円、保守は入っていませんが、3年間の間には壊れる部品もあると思うので 8万円を追加して、合計 20万円が HW価格。

両方足して 1,370万円が、システム価格となりました。

あと、検証の途中では Partitioning Optionと Advanced Compressionを使うつもりなので、必要な時にシステム価格に反映させます。

今までの検証結果をまとめると、(為替レートは 85円/ドル)


blocksizeLinux I/O SchedulerQphH@32GBUSD/QphH@32GBPrice(Yen)
8KBcfq974163.051350万円
32KBcfq986161.041350万円
32KBnoop4,70733.731350万円

33ドル/QphHまで来たので、先日書いた

  • 1000GBで 140,181 QphH 12.15 USD/QphH
  • 3000GBで 198,907 QphH 16.58 USD/QphH

にも、もうそろそろ手が届きそうかな?

続きを読む »
投稿者 時刻: 1 件のコメント:
ラベル: , , ,

2011年4月8日金曜日

[memo] Oracle Linux 6 に Gridをインストールする... (その2) ...も玉砕

Oracle Linux 6に Oracle 11gR2を導入しようとしてハマった話の続き。
前回はこちら。


ASM環境を構築して create databaseしたところまでは出来たのですが、実際にデータをロードして selectしてみたら Corrupt Blockのエラーが多発してしまいました。
この状況はまだクリア出来ておらず、現在進行形です。
以下に状況をまとめていきます。

Oracle Linux 6 (x86_64)
Oracle Database 11.2.0.2

現象としては普通に selectすると alertlogに
  1. Hex dump of (file 5, block 1119186) in trace file  
  2. /home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_p004_17683.trc  
  3. Corrupt block relative dba: 0x015113d2 (file 5, block 1119186)  
  4. Bad header found during user buffer read  
  5. Data in bad block:  
  6.  type: 6 format: 2 rdba: 0x015d409a  
  7.  last change scn: 0x0000.000f1bbd seq: 0x2 flg: 0x04  
  8.  spare1: 0x0 spare2: 0x0 spare3: 0x0  
  9.  consistency value in tail: 0x1bbd0602  
  10.  check value in block header: 0xd126  
  11.  computed block checksum: 0x0  
  12. Reading datafile '+DATA/orcl/datafile/tpch_8k.263.747829685' for corruption at  
  13. rdba: 0x015113d2 (file 5, block 1119186)  
  14. Read datafile mirror 'DATA_0002' (file 5, block 1119186) found valid data  
のメッセージが延々と続きます。
Corrupt Blockがあったのでミラーから読んだよ、というものです。
ちなみに ASMの冗長性は normalです。

調査開始。

今回の環境では iSCSIで接続しているディスクたちを ASMディスクとして使用しています。
  1. [root@node00 ~]# iscsiadm -m session  
  2. iser: [13] 10.2.0.135:3260,1 iqn.1995-07.com.insight-tec.node15:storage.raid0  
  3. iser: [14] 10.2.0.134:3260,1 iqn.1995-07.com.insight-tec.node14:storage.raid0  
  4. iser: [15] 10.1.0.133:3260,1 iqn.1995-07.com.insight-tec.node13:storage.raid0  
  5. iser: [16] 10.1.0.131:3260,1 iqn.1995-07.com.insight-tec.node11:storage.raid0  
  6. iser: [17] 10.2.0.136:3260,1 iqn.1995-07.com.insight-tec.node16:storage.raid0  
  7. iser: [18] 10.1.0.132:3260,1 iqn.1995-07.com.insight-tec.node12:storage.raid0  
  8.   
  9. [root@node00 ~]# oracleasm listdisks  
  10. VOL1  
  11. VOL2  
  12. VOL3  
  13. VOL4  
  14. VOL5  
  15. VOL6  
※ ここで iscsiadmの結果の一番左に tcpではなく iserと表示されているに気づきました? iSER(iSCSI Extention for RDMA)は、iSCSIのデータ転送を TCPではなく RDMA(Remote DMA)を使うことで高速化する技術です。そのあたりの詳しいことは後日まとめるつもり。

そのディスクたちの状況を調べていきます。

  1. SQL> select GROUP_NUMBER, DISK_NUMBER, MOUNT_STATUS, HEADER_STATUS, STATE, REDUNDANCY, FAILGROUP, PATH from v$asm_disk;  
  2.   
  3. G D MOUNT_S HEADER_STATU STATE    REDUNDA FAILGROUP    PATH  
  4. - - ------- ------------ -------- ------- ------------ ---------------------------  
  5. 1 5 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0005    /dev/oracleasm/disks/VOL6  
  6. 1 4 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0004    /dev/oracleasm/disks/VOL5  
  7. 1 3 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0003    /dev/oracleasm/disks/VOL4  
  8. 1 2 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0002    /dev/oracleasm/disks/VOL3  
  9. 1 1 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0001    /dev/oracleasm/disks/VOL2  
  10. 1 0 CACHED  MEMBER       NORMAL   UNKNOWN DATA_0000    /dev/oracleasm/disks/VOL1  
  11.   
  12. SQL> select DISK_NUMBER, HOT_USED_MB+COLD_USED_MB USED_MB, READS, WRITES, READ_ERRS, WRITE_ERRS from v$asm_disk;  
  13.   
  14. DISK_NUMBER    USED_MB      READS     WRITES  READ_ERRS WRITE_ERRS  
  15. ----------- ---------- ---------- ---------- ---------- ----------  
  16.           5      11035      18319      63000          0          0  
  17.           4      11035      16104      61260          0          0  
  18.           3      11038      15517      64942          0          0  
  19.           2      11038      15802      66461          0          0  
  20.           1      11034      12914      67519          0          0  
  21.           0      11040      16818      66523          0          0   
READ_ERRS, WRITE_ERRS共に 0なので、ASM的なエラーは検知していないよう。
エラー内容もレイヤーとしては ASMではなく datablockのエラーに見えます。

今回報告されたブロックのダンプを取ってみます。
  1. SQL> alter system dump datafile 5 block 1119186;  

それと、トレースに吐き出されているブロックダンプを比較する。

これがトレースに吐き出されていた情報
  1. Corrupt block relative dba: 0x015113d2 (file 5, block 1119186)  
  2. 7F5048652000 0000A206 015D409A 000F1BBD 04020000  [.....@].........]  
  3. 7F5048652010 0000D126 00000001 000122E0 000F0AAF  [&........"......]  
  4. ....  
  5. 7F5048653FF0 74756F62 65687420 65747320 1BBD0602  [bout the ste....]  
  6. Bad header found during user buffer read  
  7. Data in bad block:  
  8.  type: 6 format: 2 rdba: 0x015d409a  
  9.  last change scn: 0x0000.000f1bbd seq: 0x2 flg: 0x04  
  10.  spare1: 0x0 spare2: 0x0 spare3: 0x0  
  11.  consistency value in tail: 0x1bbd0602  
  12.  check value in block header: 0xd126  
  13.  computed block checksum: 0x0  
  14. Reading datafile '+DATA/orcl/datafile/tpch_8k.263.747829685' for corruption at rdba: 0x015113d2 (file 5, block 1119186)  

これが自分でダンプした情報
  1. Start dump data blocks tsn: 6 file#:5 minblk 1119186 maxblk 1119186  
  2. Block dump from cache:  
  3. Dump of buffer cache at level 4 for tsn=6, rdba=22090706  
  4. Block dump from disk:  
  5. buffer tsn: 6 rdba: 0x015113d2 (5/1119186)  
  6. scn: 0x0000.000f19dd seq: 0x02 flg: 0x04 tail: 0x19dd0602  
  7. frmt: 0x02 chkval: 0x54c9 type: 0x06=trans data  
  8. Hex dump of block: st=0, typ_found=1  
  9. Dump of memory from 0x00007FF47C991A00 to 0x00007FF47C993A00  
  10. 7FF47C991A00 0000A206 015113D2 000F19DD 04020000  [......Q.........]  
  11. 7FF47C991A10 000054C9 00000001 000122E0 000F0AAE  [.T......."......]  
  12. ....  
  13. 7FF47C9939F0 73202E73 6E656C69 65722074 19DD0602  [s. silent re....]  

データの中身から Consistency value, checksum, 果てには SCNまでまるっきり異なります。当然ですが、エラーが出てからデータの更新はしていません。ミラーから読み込んだデータで上書きされたとしか考えられません。あるいは、コマンドの実行方法を間違えているのか?

今回問題のテーブルに select count(*) をかけるのですが、毎回 Corruptと報告されるブロックアドレスが異なります。ミラーデータから修復されているとしたら、そのうちエラーは出なくなりそうなものですが、何度実行しても同じくらいの数のブロックがエラーと報告されます。

dbverifyかけてみました。

  1. $ dbv USERID=sys/*** FILE='+DATA/orcl/datafile/tpch_8k.263.747829685' FEEDBACK=100  
  2. ...  
  3. Total Pages Marked Corrupt   : 6  
  4. ...  
  5. $ dbv USERID=sys/*** FILE='+DATA/orcl/datafile/tpch_8k.263.747829685' FEEDBACK=100  
  6. ...  
  7. Total Pages Marked Corrupt   : 13  
  8. ...  

何度やっても Corrupt Blockが消えないし、毎回異なるブロックが報告されるという状況は変わらず。読みながら、ブロックを修復しつつ、他のブロックを壊している ような感じです。

ここで、一応諦めました。

ASMは、OS Versionや Oracle Versionを、非常にセンシティブに選びます。
きっと 11gR2が Oracle Linux 6対応するときは、新しい必須パッチが出るのだと予想。

ここまでの収穫

ASM内部情報についてまとめたサイトを見つけました。
11gR1 から 11gR2で ASMの内部構造がかなり変更されているのがわかります。

ASM Metadata and Internals
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2011年4月7日木曜日

[memo] Oracle Linux 6 に Gridをインストールする...

Oracle Linux 6 + Oracle 11gR2(11.2.0.2)で ASM環境を構築する必要があったので、
何の気なしに片手間で作り始めたら、かなりハマりました。
忘れないうちに、Oracle Linux 5.6 の時との違いについてポイントをまとめておきます。

ちなみに、このポイントをクリアしても、動作するわけでありません っっ
あるいは、解決方法知っている人がいたら大募集。

更に、Oracle 11gR2は、まだ Oracle Linux 6を正式サポートしていませんので、チャレンジャーな感じです。

Oracle Linux 6
E-Deliveryからダウンロード
デフォルトの Unbreakable Enterprise Kernelを導入
導入するときに oracleasm-support-2.1.5-1.el6.x86_64 は、必ず入れる。

逆にこれ以外は oracleasm関連パッケージはありませんでした。

Oracle Grid Infrastructure 11.2.0.2.0
ASMディスクの構成を行い、インストーラを実行。構成チェックで root.shを実行するとエラーになる。
  1. # .../root.sh  
  2. ...  
  3. ohasd failed to start  
  4. Failed to start the Clusterware. Last 20 lines of the alert log follow:  
  5. 2011-04-01 11:55:49.329  
  6. [client(25625)]CRS-2101:The OLR was formatted using version 3.  
  7. 2011-04-01 11:55:55.191  
  8. [client(25654)]CRS-1001:The OCR was formatted using version 3.  
  9. [client(25696)]CRS-10001:CRS-6021: No msg for has:crs-6021 [l][unlimited]  
  10. [client(25697)]CRS-10001:CRS-6021: No msg for has:crs-6021 [n][65536]  
  11.   
  12. ohasd failed to start at /home/oracle/app/oracle/product/11.2.0/grid/crs/install/roothas.pl line 325.  
  13. /home/oracle/app/oracle/product/11.2.0/grid/perl/bin/perl -I/home/oracle/app/oracle/product/11.2.0/grid/perl/lib -I/home/oracle/app/oracle/product/11.2.0/grid/crs/install /home/oracle/app/oracle/product/11.2.0/grid/crs/install/roothas.pl execution failed.  
  14. #  
  1. CRS-06021: Could not set system resource limits for Clusterware: "ulimit -string string".  
メッセージからすると ulimit -l と -n の変更が出来ないと言っている。
裏で取得していた strace(1)でも同じエラーが出ていた。
  1. setrlimit( RLIMIT_MEMLOCK,{rlim_cur=RLIM_INFINITY,rlim_max=RLIM_INFINITY})  
  2.  = -1 EPERM (Operation not permitted)  
  3. setrlimit( RLIMIT_NOFILE,{rlim_cur=64*1024,rlim_max=64*1024})  
  4.  = -1 EPERM (Operation not permitted)  

/etc/security/limits.confに以下を追記する
* soft nofile 2048
* hard nofile 131072
* soft memlock 64
* hard memlock unlimited


ulimitのエラーは出なくなったが、相変わらず同じ場所でエラーとなる。
root.shに strace(1)をかけて見てみると
ctsctl.binのプロセスが /var/tmp/.oracle/sOHASD_UI_SOCKET というソケットファイルが出来るのを待っている様子が見て取れる。
  1. 12964 socket(PF_FILE, SOCK_STREAM, 0)   = 5  
  2. 12964 access("/var/tmp/.oracle/sOHASD_UI_SOCKET", F_OK) = -1 ENOENT (No such file or directory)  
  3. ....  
  4. CRS-04124:Oracle High Availability Services startup failed.を出力  
  5. ....  
  6. nanosleep(...)  
  7. ...この繰り返し...  

OHASが立ち上がっていないのが原因か。
なので ohasd.binというプロセスを見ていくと、
  1. 12969 mknod("/var/tmp/.oracle/npohasd", S_IFIFO|0666) = 0  
  2. 12969 open("/var/tmp/.oracle/npohasd", O_WRONLY <unfinished ...>  
ここが最後の行になっている。NamedPipeの open(2)が終了していない???
じゃあ、ここから吸いだしてあげたらいいじゃないか、ということで
  1. # dd if=/var/tmp/.oracle/npohasd  
を実行したら、ohasd.binが動き出した！！
一応必要なプロセスが全部動き始めたようで roo.shの実行が終了しました。

後でググったら、 CRS-4639: Could not contact Oracle High Availability Services

の資料でも ddコマンド使う という方法が載っていました。前のバージョンですが。
ddコマンドで動かすというのは、かなり乱暴だと思いますが、それが対応策で載っているあたりがオラクルです。syslogdが動作していないと発生する、というような記述もあるので、時間があれば後で調べてみようと思います。

ohasdが /var/tmp/.oracle/npohasdの open(2)で止まっていたら、dd(1)で先にすすめることが出来る。

ちなみにOS再起動するたびに dd(1)を実行しています。。トホホ

Oracle Database 11.2.0.2.0
Database自体の導入はスムーズに進みました。
また、今回のデータベースは SYSTEM表領域などはファイルシステム上に、ユーザーデータだけをASM上に作成しています。
で、データを入れてパフォーマンスを測りだしたら、Corrupt Blockのエラーが多発。。。。

データのロード方法などをいくつか試していますが、今のところ、ある程度以上のデータ量だと確実に再現しています。

詳細は次回で。
投稿者 時刻: 0 件のコメント:
ラベル: , , , , , ,

2011年4月6日水曜日

TPC-H Linux I/O Schedulreを変えてビックリ

引き続きTPC-Hの検証。

Linux I/O Schedulerには4種類ありますが、新久保君の TPC-Cの検証で Linux I/O Schedulerによるパフォーマンスの違いは無い という結果が出ています。

が、今回はおどろくべ結果が！！！


blocksizeLinux I/O SchedulerElapsedQphH@32GB
32KBcfq3,342 sec986
32KBnoop678 sec4,704


Linux I/O Schdulerを noopに変えただけで約5倍のパフォーマンスアップとなりました！

SSDの場合、ディスクヘッドのシークが無いので、何もスケジュールしない noopが有利だと言われていますが、こんなに異なるとは予想外。
リソース消費量についても処理時間を裏付ける結果となりました。




throughputは 133MB/secから 652MB/secへ。
IOPSは 1,668から 8,211へ。そのまま処理時間の差と同じです。
ちなみにトータルのディスク読み込み量は約45GBでほぼ同じでした。(IO Schedulerしか変えていないので当たり前)

この違いはどこから来ているのか。
strace(1) に -T -tttオプションを付けて、Oralceのバックグラウンドプロセスの発行する pread(2)のレスポンス時間および、pread(2)が発行されるインターバルを見てみた。

-T: system call内の滞留時間をマイクロ秒単位で出力。
-ttt: 出力各行にマイクロ秒単位の時刻を出力


Oracleバックグラウンドプロセスが読み込みをするときは pread(2)が連続して呼び出されます。
pread(2)がリターンしてきてから、次のpread(2)が発行されるまではどちらもほぼ同じ時間で、約0.1~1msec前後でした。IOサイズは 1MBで同じであり、Oracle内部処理は、IO Schedulerに左右されませんから、同じのも当たり前と言えば当たり前です。

ところが、pread(2)自体にかかる時間が cfqの場合は 10~100msecでかなりばらつきがあります。対して noopの場合は 約10msecであり、かなり安定していました。
  • この処理は Parallel Degree=6で行っているので、複数プロセスから同時にIOリクエストが来ている。
  • pread(2)にかかる時間と Oracle内部処理時間を比較すると 1/100 ~ 1/1000 のオーダーなので、読み込み処理時は、ほぼすべての時間がディスクIO待ち。つまり、ディスクには常に複数リクエストがキューイングされた状態になっている。
  • 従って cfq処理のオーバーヘッドが、今回の性能差になっている。

上記推測を元に、再度 vdbenchによる Linux IO Scheduler別の性能比較を行ってみましたが、結果は以下。




1-Threadこそ noopの方が早いですが、それにしても5倍の差はありません。4-Threadでは cfqと noopの有意な差はありませんでした。今回はパラレルクエリーなので cfq, noopの差は無いはずです。
ここまで書いてきて、もしかして Threadと Processで挙動が異なるかも、という気もしましたが、普通に考えると、リクエストキューはデバイスごとに作成されるしなぁ～
ということでまだ理由がわかっていません。



今日の結論は、
SSD上のファイルシステムにOracleデータファイルを作成する場合は、IO Schedulerは必ず noopで！

本日の結果: 4,704 QphH@32GB



次回はOracleのパラメータで filesystemio_options を調整してみる。
投稿者 時刻: 0 件のコメント:
ラベル: , , , , , ,
登録: 投稿 (Atom)