Win設定

In-Memory Parallel Queryの続き

データベースが大量のメモリーにアクセスするのがIn-Memory Parallel Queryだから、Large Pageサポート機能を検証してみた。

ラージ・ページのサポートは、Oracle Database 10gリリース1（10.1）以上の機能です。ラージ・ページのサポートにより、Windows Server 2003で実行されているメモリー集中型のデータベース・インスタンスのパフォーマンスが向上します。新たに導入されたオペレーティング・システム・サポートを利用することにより、Oracle Database 10gリリース1（10.1）以上では、プロセッサ・メモリー・アドレッシング・リソースをより効率よく使用できるようになりました。具体的には、ラージ・ページのサポートが有効になっていると、システムのCPUはRAM内のOracle Databaseバッファにより高速にアクセスできるようになります。4KBの増分でバッファをアドレッシングするかわりに、CPUはデータベース・バッファをアドレッシングする際にPhysical Address Extension（PAE）モードでは2MBのページ・サイズ、非PAEモードでは4MBのページ・サイズを使用するように指示されます。

Oracle Databaseプラットフォーム・ガイド　11gリリース1（11.1） for Microsoft Windows　E05885-03

まずは、メモリ内のPageロック機能権限を与える：

そして、レジストリにORAL_LPENABLE=1をセットする：

一応Rebootして、
THP-Hベンチマークを行うと：

nocompressでIn-Memory Parallel Queryの時の結果と比べると：

少し上がったようにも見えるが、ほとんど変わらない。

DB_BUFFER_CACHEが100GBなんていう環境であれば効果はあるのだろう。
非ページング対象になるという意味ではlock_sgaやnailed_sgaパラメータと似ている。

以前書いたExpress 5800 128GBメモリ搭載機クラス用の設定だと思う。

TPC-Hベンチマークの続き

前回の「result_cacheで更に50%アップ」と同じようにOS File Cacheも働いてくれる。

例によって、Heavy Top5から（今回はSSDではなくHDDを使用）、

SQL> ALTER SESSION FORCE PARALLEL QUERY PARALLEL 1;
SQL> alter system flush buffer_cache;
SQL> select c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, sum(l_quantity)
  2  from customer, orders, lineitem
  3  where o_orderkey in
  4  ( select l_orderkey
  5  from lineitem
  6  group by l_orderkey
  7  having sum(l_quantity) > 314)
  8  and c_custkey = o_custkey
  9  and o_orderkey = l_orderkey
 10  group by c_name, c_custkey
 11  , o_orderkey
 12  , o_orderdate
 13  , o_totalprice
 14  order by o_totalprice desc, o_orderdate;

10行が選択されました。

経過: 00:01:13.63

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     233827  consistent gets
     130508  physical reads
          0  redo size
       1463  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
         10  rows processed

パラレル度=1で全てfull scanされ1分13秒かかった。

もう一度、buffer_cacheをflushしてから実行すると：

SQL> alter system flush buffer_cache;
SQL> select c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, sum(l_quantity)
  2  from customer, orders, lineitem
  3  where o_orderkey in
  4  ( select l_orderkey
  5  from lineitem
  6  group by l_orderkey
  7  having sum(l_quantity) > 314)
  8  and c_custkey = o_custkey
  9  and o_orderkey = l_orderkey
 10  group by c_name, c_custkey
 11  , o_orderkey
 12  , o_orderdate
 13  , o_totalprice
 14  order by o_totalprice desc, o_orderdate;

10行が選択されました。

経過: 00:00:12.60

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     233827  consistent gets
     130508  physical reads
          0  redo size
       1463  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
         10  rows processed

physical reads量は同じにもかかわらず、12.6秒で終わった。
約6倍短縮された。

今度はflushしないで、もう一度：

SQL> /

10行が選択されました。

経過: 00:00:03.01

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     233827  consistent gets
          0  physical reads
          0  redo size
       1463  bytes sent via SQL*Net to client
        519  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
         10  rows processed

physical readsなしで、3秒で終わった。

まとめてみると、

ということになる。

「Exadata V2はメモリが72GB搭載」の中で、

対して、こちらはRACではない。メモリが多ければ余りはファイルキャッシュとして働いてもらえる。だからその分を見越してたくさん余らしておく。

と書いた。Windows7で16GBの実メモリを搭載し、そのメリットを改めて確認した。

そして「Oracle Closed World 」の中で書いた、

例えば、夕方に出力する「出荷ステータス・レポート」が毎日1時間かかる。
このコストを削るのに「廉価なminiスナップショットマシン」を作ればいい。1分で帳票を出してくれるDWHの出来上がりだ。

という話に、この機能は大きく貢献する。

流行だからって何でもかんでもLinuxでやる必要はない。。。とWindows嫌いが、心を入れ替えました。
因みに、LinuxでもUnixでもOS file cacheは有ります。

最後に、
今回購入したメモリ（DDR3メモリ）は、現在4GBで1万円以下となった。（3ヶ月弱で30%近く安くなった）
16GBだと35000円程度で買える。

前回のテストではI/O buffer sizeを最適化することによりdb_file_multiblock_read_count = 64でも安定するようになった。そして、全体を通してみると、この64の結果が一番よい：
db_file_multiblock_read_count = 64, _db_file_direct_io_count = 524288

db_file_multiblock_read_count = 128, _db_file_direct_io_count = 1048576画面右上に出ている数値は最後のサンプリングタイミングでの数値。平均ではない。

今回の試作機はKingstonのお買い得SSD4本でRAID-0を構築した。

そのときのStrip Sizeは128KBとした。

このサイズはIntel Matrix Storage ManagerでRAID0を設定するときの最大値だ。
そして、exFAT形式のファイルをフォーマットするときに、

Allocation Unit Sizeを512KBとした。128KB x 4本 = 512KB

その結果

TPC-Hベンチマークの続き

前回のSQLを見てみると、やはりTPC-H。TPC-Cとはぜんぜん違う。
実行結果もたくさん返される：

TPC-Cのときは：

ネットワークバッファを広げてみる。
sqlnet.ora

DEFAULT_SDU_SIZE=32768
RECV_BUF_SIZE=524288
SEND_BUF_SIZE=524288

Oracle用語集から：

セッション・データ・ユニット（session data unit: SDU）
Oracle Netがネットワーク間でデータを転送する前にデータを配置するバッファ。Oracle Netがバッファ内のデータを送信するのは、データ送信が要求されたとき、またはバッファがデータでいっぱいになったときである。

hammeroraでTPC-Hベンチマークを再び行い、ディスク転送量をみる：

前回のほぼ最大が400MB/sから安定した420MB/s強に改善された。5%アップだ。

もう少し突っ込んでIPC接続でもテストをした(tnsnames.oraにORACLE2を追加)：

前回のテストで書き込みキャッシュの有効性を確認できた。

しかし、Shared Diskで使う場合はこの設定をしてはいけない。

停電対応のためだけにDisableにしなさいというのであればUPS電源を確保した環境であれば補える。
RACクラスター構成も使わないのであれば、メモリ障害などの危険性もないわけではないが、

これほど有効な設定を使わない手はない。

前にやったベンチマーク結果をもう一度おさらいすると：
メモリのWriteアクセススピードは約7.6GB/s

ディスクはTPC-Cの場合はランダムWriteを注目すべきなので約2.6MB/s

おおよそ2900倍の差がある。

最後に、
書き込み負荷でtpmが回らなかったのだから、4本のHDDでストライピングし解決したとすると、
当然tpmは上がり、CPUもある程度Busyになってくる。
そこでRAC構成にしてスケーラビリティを上げようとすると、書き込みキャッシュがいきなり「禁じ手」になる。
結果、2台のRACで1台で出したtpmと「同じ程度」しか出せない。
RACでスケーラビリティを上げようと思ったら4本のストライピングじゃ全然足りない。なぜならばWrite Busyを少しでも発生させると2900倍の差が発生するからだ。

VM環境テストで性能が上がらないケースにも当てはまる。

TPC-Cベンチマークの番外編として、Windows7の書き込みキャッシュ機能の調査をしました。

今回のテストではデバイスマネージャのプロパティ設定にある

「書き込みキャッシュ ポリシー」→デバイスの書き込みキャッシュを有効にするだけで行いました。

デバイスでWindowsによる書き込みキャッシュバッファのフラッシュをオフにするもテストしてみました：

tpmが少し安定しているのがわかります。

そして、最後にすべてをオフにしました：

書き込みキャッシュがとても有効なことがわかります。

そうか、、、前回の安定しない「波形」は書き込みキャッシュの周期的なフラッシュだったんだな。