2016年06月16日

[Oracle]統計情報はリアルタイム化の夢を見るか?

 <最初に>

9iの頃まではANALYZEとも呼ばれていた統計情報、当時は「ANALYZEすると遅くなる」「RULEヒントを付けた方が良い」 という都市伝説もありました。
10g以降、ルールベースオプティマイザが廃止された為、仕方なく統計情報と向き合う様になったという方も居るかも知れません。私がそうです。

Oracle Databaseを運用する上で、統計情報の収集は重要なテーマです。
統計情報を収集せずに固定化する運用としているシステムもあれば、標準設定の平日22時の自動収集でも問題無いシステムもあります。

統計情報を固定化する主な理由は「統計情報の変動」に起因する「実行計画の変動」を回避する為です。
そもそも「統計情報の変動」は「格納データの変動」に起因します。
日付データで例えると、新規登録・更新される日付や検索される日付範囲は、システム日付と共に変わります。
古い日付の統計情報で固定化してしまうと、格納データと固定化した統計情報は日々乖離していきます。
統計情報には行数以外にも、最大値、最小値、ヒストグラム等が含まれます。
格納データを全件アクセスする広範囲の検索条件でも、統計情報上では最大値から外れた検索条件として見え、 INDEX検索が有利とコストベースオプティマイザが判断する危険性があります。
統計情報固定化だけでは実行計画を固定化出来ず、格納データや検索条件も固定化しなければなりません。
そこまですると固定コンテンツ化してしまい、更新処理が得意なOracle Databaseを使うメリットが無くなってしまいます。
昔は統計情報固定化という運用を取る事もありましたが、次第に「格納データと統計情報の乖離」による弊害に気を遣う事が多くなってきました。

コストベースオプティマイザが正しい判断をする為には、正しい統計情報が必要です。
しかし統計情報収集にはいくつか問題点があります。
11g以降改善されてきてはいますが、大量データが含まれるテーブルでは統計情報収集に長時間掛かります。
更に統計情報収集はバッチ処理なので、実行タイミングに悩む事があります。
短期間で削除と登録を行う揮発性の高いテーブルや、統計情報収集後に発生したデータでは、前述した「格納データと統計情報の乖離」 による弊害が発生する可能性があります。
適応計画や適応統計で、ハズレの実行計画の検知や改善は行えますが、初回ペナルティを受ける可能性は残ります。

そこで「統計情報のリアルタイム化」という夢を見たのです。
統計情報がリアルタイム化されると、下記の様なメリットがあります。
・長時間掛かるバッチ処理での統計情報収集処理自体が不要若しくは高速化されます。
・「格納データと統計情報の乖離」が無くなる事で、ハズレの実行計画を引く可能性が低下します。

そもそも統計情報には次のものがあります。
・表統計
 行数
 ブロック数
 行の平均長さ
列統計
 列内の個別値(NDV)数
 列内のNULL数
 データ配分(ヒストグラム)
 拡張統計
・索引統計
 リーフ・ブロック数
 レベル数
 索引クラスタ化係数
・システム統計
 I/Oパフォーマンスと使用率
 CPUパフォーマンスと使用率

この内、格納データに依存するのは、表統計、列統計、索引統計です。
セグメントやブロックの情報は元々ディクショナリでリアルタイム管理されています。
行数のリアルタイム管理も難しくは無さそうです。
リアルタイム化が難しそうな箇所は、列統計全般と索引クラスタ化係数だと思います。

 <案1.ラムダアーキテクチャ

少し前にクラウドインテグレーターの情報収集をした際に「ラムダアーキテクチャ」というキーワードを聞きました。
バッチ処理とリアルタイム処理を融合したアーキテクチャで、AWSのRedShiftとKinesisを利用して実装したとの事でした。

DBMS_STATSでの統計情報収集はバッチ処理なので、リアルタイム処理で統計情報を収集する仕組みが別にあれば良さそうです。

 <案2.インメモリカラムストア

12cにて採用されたIn-Memory Optionで、インメモリカラムストアが使用可能となりました。
インメモリカラムストアは列情報なので、列統計全般と索引クラスタ化係数の算出にも使えそうです。
テーブルからインメモリカラムストアに読み込むポピュレーションの後続ジョブとして、インメモリカラムストアから統計情報を逐次収集する事で、 高精度な統計情報を低負荷で収集出来そうです。

ポピュレーションは厳密に言えばリアルタイム処理ではありませんが、DBMS_STATSでの統計情報収集と比べればリアルタイムに近付きます。
インメモリカラムストア若しくはそのサブセットの利用は、統計情報のリアルタイム化に有効だと思います。

インメモリカラムストアには問題もあります。
再起動後は再ポピュレーションしてメモリに乗せなければならない点です。
暖機運転が終わらないと、インメモリ処理が実行出来ません。

 <案3.ローカル管理統計情報

現在の統計情報はSYSTEM表領域内のディクショナリに、履歴はSYSAUX表領域に格納されています。
統計情報をリアルタイムで更新すると、競合が発生するかも知れません。
ディクショナリ管理表領域でも聞いた事のあるような話です。
8iにて採用されたローカル管理表領域で、エクステント情報をヘッダ部のビットマップで管理するようになりました。
統計情報がリアルタイム化される際には、統計情報もローカル管理される様になるかも知れません。
「ローカル管理統計情報」とでも名付けます。

 <案4.適応インメモリ・リアルタイム統計情報

ブロック数やエクステント数の上限が決まっているローカル管理表領域のビットマップは、ヘッダ部の固定領域に確保されています。
統計情報のデータ量は、列数、索引数、ヒストグラム、拡張統計に応じて変動します。
データ量が変動する統計情報は、固定領域ではなく、エクステント単位に拡張出来た方が良いかも知れません。
データ用エクステントとは別に、統計情報用エクステントを用意する事になりそうです。

更に、インメモリカラムストア用エクステントも用意して、シャットダウン前や定期的にメモリ内容をディスクへ保存する事が出来れば、 再起動後の再ポピュレーションの負荷を削減出来ます。
インメモリカラムストアは1MBプールと64KBプールで管理されており、あらかじめ圧縮されている為、 同じサイズかそれより大きなサイズのエクステントに保存する事になりそうです。

データ用表領域は UNIFORM SIZE nM で均一に設定される事もあるので、 統計情報・インメモリカラムストア用エクステントとはサイズが異なる場合があります。
統計情報・インメモリカラムストア用エクステントは、データ用表領域ではなく、 SYSAUX表領域やフラッシュの様な高速ストレージへ保存した方が良いかも知れません。
DB_CACHE_SIZEと「Database Smart Flash Cache」の関係の様に、 INMEMORY_SIZEを高速ストレージで拡張する様な使い方も考えられます。
最近の新機能に合わせて「適応インメモリ」とでも名付けます。

統計情報の保存先は前述したローカル管理では無くなってしまい、「適応統計」は12cで既に実在する機能名なので、 「リアルタイム統計情報」とでも名付けます。

realtime_statistics

 <最後に>

「統計情報のリアルタイム化」について、こうなれば良いのに、あれが使えそう、と思う事を書き出し、 Oracle Databaseの将来について語ってみました。

posted by charade at 05:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2015年12月08日

[JPOUG Advent Calendar] Oracle on Hyper-V 2015

charade_oo4oと申します。昨年に引き続き、今年も「JPOUG Advent Calendar 2015」へ参加致します。
昨日は渡辺 剛さんの「Oracle VM Server とその周辺のもの: OpenStack for Oracle Linux R2 の様子。」でした。

今年はOracleもMicrosoftも2016年に向けた準備期間だったと思います。
Oracleは「Oracle Database 12c Release 2」、Microsoftは「Windows Server 2016」、各種イベントで2016年リリース予定の製品の情報が公開されました。
それ以外にもStandard Edition系の見直しや「Windows 10」リリースがありました。
特にHyper-V環境はInsider向けの新Buildで度々見直しが必要でした。
Docker、Nested Hyper-V、新技術実現の為の変革なのでしょう。
Windows10は検証時点では頻繁にBuildが上がっていた為、今回はWindows8.1のClient Hyper-Vを使用しました。

 <1.きっかけ>

Oracle自身は12.1を薦めていますが、現時点では11.2と12.1のどちらで構築するのが良いか悩みます。
12cの導入は12.2のリリースを契機に本格的に進むのではないかと思います。
11.2のリリースが2009年なので、7年振りのRelease 2になります。
中には12.2がリリースされてから勉強しようと考える方も居るかも知れません。
きっかけとしては間違いではないと思います。
但しそれで充分かと言うと、否と言わざるを得ないでしょう。
Oracle Databaseは1-2年毎にリリースされるパッチセットの度に結構変わるので、その都度勉強が必要です。
Oracle Database Cloudではそれより早く新機能が提供されるかも知れません。
Microsoft Azure SQL Databaseはほぼ毎月機能追加があり、オンプレミスのSQL Serverとは別物の進化を遂げています。
継続的な勉強が必要なら、12.1での勉強も通過点に過ぎません。

http://www.oracle.com/technetwork/jp/database/upgrade/overview/upgrade-and-migrate-12c-ja-part1-2367968-ja.pdf
Oracle Database 12cへのアップグレード/移行とデータベース統合(Part 1)

「地球はまだ丸い(The earth is still a sphere)」
プラガブル・データベース使用可否のガイドに掲載されていた言葉です。
12cリリース当初は「まだ使わなくても良い」でした。

http://docs.oracle.com/cd/E57425_01/121/UPGRD/deprecated.htm#BABDBCJI
8.1.1 非CDBアーキテクチャの非推奨

しかし2015年のアップグレード・ガイドでは「Non-CDBは非推奨」と変わってしまいました。
今後はStandard Edition 2でもシングルテナント構成を検討する必要がありそうです。
12.2でもPDBは機能追加され、「PDB Relocate」ではライブマイグレーションが可能となる様です。

PDB間の通信はdblinkを使用する必要があるとの事でした。
PDB間通信にはどの位の帯域があるのか、Hyper-V上の仮想マシンで試行錯誤してみました。

 <2.転送量が少ない>

帯域を調べる為、大量のデータを流して、処理時間を計測しました。
PDB間通信を調べる前に、まずPDB内のテーブルに対してSQLPLUSから計測してみました。
・ゲストOS:2012R2で、DB:12.1.0.2 EEを実行。
・ホストOS:Windows8.1のコマンドプロンプトからSQLPLUS+Instant Clientを実行してDB接続。
・SQLPLUSで、SET TIMING ON、SET AUTOTRACE TRACEONLYを設定して、処理時間等を確認。
 (他にSET PAGESIZE 0、SET LINESIZE 1025、SET ARRAYSIZE 5000も設定。)
・SELECT文で大量データを取得。
・テストデータは12cのIn-Memory Optionを有効にしたテーブルへ格納。

構成


テストデータはINSERT SELECT文で作成しました。
INSERT /*+ APPEND */ INTO TESTTABLE (SEQNO, INFO)
SELECT LEVEL, RPAD('X',1024,'X')
  FROM DUAL CONNECT BY LEVEL <= 100000;

次に、単純なSELECT文を計測しました。
SELECT T.INFO FROM TESTTABLE T;

100000行が選択されました。

経過: 00:00:06.97

実行計画
----------------------------------------------------------
Plan hash value: 2221197626

----------------------------------------------------------------------------------------
| Id  | Operation                  | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |           |   100K|    97M|   196   (1)| 00:00:01 |
|   1 |  TABLE ACCESS INMEMORY FULL| TESTTABLE |   100K|    97M|   196   (1)| 00:00:01 |
----------------------------------------------------------------------------------------

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          3  consistent gets
          0  physical reads
          0  redo size
     506294  bytes sent via SQL*Net to client
        761  bytes received via SQL*Net from client
         21  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     100000  rows processed

In-Memory Optionが効いており、0  db block gets、3  consistent gets、0  physical reads です。DISK I/Oは発生していません。
しかし肝心のデータ転送量は、506294  bytes sent via SQL*Net to client。約494KByteなのでかなり少ないです。
1カラム1KByteで100000行取得しているので、100MByte弱は転送するはずです。

データ作成時のSELECT文のみを抜粋しても、同様の結果でした。
SELECT RPAD('X',1024,'X')
  FROM DUAL CONNECT BY LEVEL <= 100000;

     506308  bytes sent via SQL*Net to client

SQLPLUSはDBサーバの仮想マシン外から実行した為、タスクマネージャからネットワークの使用帯域を確認可能です。
DBサーバ=>クライアントの使用帯域は608kbpsしか出ていません。

試行錯誤した所、どうやらSQL*Netは連続データを圧縮する事が判りました。INDEXのCOMPRESSと同じ様な動作です。
12cではSQLNET.COMPRESSION=ONでデータ圧縮が出来る様になりました。
9i等の以前のバージョンのSQL*Netでは連続データを圧縮します。

データが連続しなければ圧縮も効かない様で、行毎に異なる値を返すSELECT文では大量データを転送する様になりました。
SELECT DECODE(MOD(LEVEL,2),1,RPAD('X',1024,'X')
                            ,RPAD('Y',1024,'Y'))
  FROM DUAL CONNECT BY LEVEL <= 100000;

  103424345  bytes sent via SQL*Net to client

DBサーバ=>クライアントの使用帯域をタスクマネージャで確認すると93.6Mbpsまで上がりました。
今度はSQLPLUSのFETCHがネックとなって、100Mbps程度で頭打ちとなっている様です。

 <3.FETCH見直し>

単純SELECT文から、PL/SQLのBULK COLLECTへ変更しました。
テストデータも不連続データへ入替。
1ブロック内に偶数行(6行)含まれていた為、ORDER BY指定無でも不連続データでSELECTされました。
100000行では実行時間が短過ぎたので、10倍の1000000行へ増加。
1回では実行時間が短過ぎたので、FOR LOOPで10回実行。
今回の環境ではBULK COLLECTのLIMITは50000件あたりで処理速度が頭打ちでした。
DECLARE
  BULK_SIZE CONSTANT PLS_INTEGER := 50000;
  CURSOR C_INFO IS
  SELECT T.INFO FROM TESTTABLE@PDB T;
  TYPE T_INFO IS TABLE OF C_INFO%ROWTYPE INDEX BY BINARY_INTEGER;
  V_INFO T_INFO;
BEGIN
  FOR I IN 1..10
  LOOP
    OPEN C_INFO;
    LOOP
      FETCH C_INFO BULK COLLECT INTO V_INFO LIMIT BULK_SIZE;
      EXIT WHEN V_INFO.COUNT = 0;
    END LOOP;
    CLOSE C_INFO;
  END LOOP;
END;
/

PDB間通信の確認と一緒に、仮想マシンを複数台使用して、仮想マシンのDB間でも確認しました。
WindowsとLinuxの異種プラットフォーム間でも確認した所、いくつか注意が必要な点がありました。

・DB間のキャラクタセットが異なると速度激減。
 最初、LinuxはAL32UTF8、WindowsはJA16SJISTILDEでDB作成していました。
 しかし、キャラクタセット変換で速度低下した為、WindowsもAL32UTF8へ統一しました。

・パケットのジャンボフレーム化で処理速度改善。
 仮想マシン間の通信では、1.5Kの通常フレームより、9Kのジャンボフレームの方が高速でした。
 Hyper-Vの仮想スイッチ、各ゲストOSのNICでジャンボフレームを有効化しました。

・dblinkはEZCONNECTで作成。
 dblinkの接続文字列には、EZCONNECTの'192.168.x.y/[service_name]'を使用しました。
 TNSNAMESのローカルネーミングメソッドも使用可能ですが、複数端末、複数DBを追加するのが大変だったので、tnsnames.ora変更不要のEZCONNECTとしました。

 <4-1.パフォーマンス・レース!>

ようやく本題のPDB間通信の速度検証する準備が整いました。
PDB間/DB間/異種PF間で6人のレーサーが登場します。
・SQLPLUSからPL/SQLのBULK COLLECTを実行し、経過時間を各構成で比較。
・仮想マシンはWindows2台、Linux2台の計4台使用。
・Windowsは2012R2、LinuxはOracle Linux 6.7(UEK)を使用。
・DBはWindows、Linux共に12.1.0.2 EEを使用。
・WindowsとLinuxの実線テーブルに同一テストデータを用意。点線テーブルはdblink経由での参照。
・Windowsの仮想マシンのDB間通信では、タスクマネージャからネットワークの使用帯域も確認。

構成


結果
構成 経過時間 帯域
@ Windows CDB内 PDB間 00:00:39.23 -
A Windows→Windows DB間 00:00:33.25 2.7Gbps
B Linux CDB内 PDB間 00:00:28.04 -
C Linux→Linux DB間 00:00:40.28 -
D Linux→Windows DB間 00:00:41.61 2.1Gbps
E Linux PDB内 00:00:05.95 -

レース結果は E >> B > A > @ > C > D でした。

・ELinux PDB内 のテーブル直接参照は、PL/SQLのBULK COLLECTがネックとなっていない事を確認する為の特別参加。帯域は15Gbps相当。
・LinuxのDB間通信 CLinux→Linux DB間 と DLinux→Windows DB間 は同程度。
・Linuxでは BLinux CDB内 PDB間 > CLinux→Linux DB間。PDB間通信は1.4倍高速。
●Windowsでは AWindows→Windows DB間 > @Windows CDB内 PDB間。PDB間通信は0.8倍低速。

この結果での問題点は、Windowsでは同一仮想マシンのCDB内のPDB間通信よりも、Hyper-Vの仮想ネットワークを経由した別仮想マシンとのDB間通信の方が速いという点です。
自組織内からの問い合わせより、他組織経由で自組織へ問い合わせた方が速い。組織的な腐敗や何らかの陰謀を連想させます。

・仮説1「WindowsでのOracle PDB間通信が腐っている。MicrosoftかOracleの陰謀。」

 <4-2.遅い処理は見つけたものの>

遅い処理を洗い出す為には、Diagnostics Packが必要ですが、Active Session Historyが便利です。
V$ACTIVE_SESSION_HISTORYでは1秒毎に情報が取得されます。特別な準備無に全セッションで1秒毎にトレースをとっている様なものです。

CDB$ROOTでV$ACTIVE_SESSION_HISTORY.SAMPLE_TIMEを処理開始/終了日時で絞り込み、必要項目を GROUP BYしました。
COUNT(*)が大きい行が遅い処理になるはずです。

BLinux CDB内 PDB間 ASH
COUNT(*) PROGRAM MODULE CON_ID SESSION_TYPE EVENT SESSION_STATE SQL_OPNAME
1 oracle@hostname (M000) MMON_SLAVE 1 BACKGROUND db file sequential read WAITING INSERT
5 sqlplus.exe SQL*Plus 4 FOREGROUND SQL*Net more data from dblink WAITING SELECT
5 oracle@hostname (TNS V1-V3) oracle@hostname (TNS V1-V3) 3 FOREGROUND ON CPU SELECT
9 oracle@hostname (TNS V1-V3) oracle@hostname (TNS V1-V3) 3 FOREGROUND SQL*Net more data to client WAITING SELECT
12 sqlplus.exe SQL*Plus 4 FOREGROUND ON CPU SELECT

@Windows CDB内 PDB間 ASH
COUNT(*) PROGRAM MODULE CON_ID SESSION_TYPE EVENT SESSION_STATE SQL_OPNAME
1 sqlplus.exe SQL*Plus 4 FOREGROUND ON CPU PL/SQL EXECUTE
2 ORACLE.EXE (PSP0) 1 BACKGROUND ON CPU
5 sqlplus.exe SQL*Plus 4 FOREGROUND ON CPU SELECT
23 sqlplus.exe SQL*Plus 4 FOREGROUND SQL*Net more data from dblink WAITING SELECT
37 ORACLE.EXE ORACLE.EXE 3 FOREGROUND SQL*Net more data to client WAITING SELECT

・ネットワーク系の待機イベントが多い。
 Linux、WindowsどちらもEVENTで、dblink側の「SQL*Net more data to client」と、テーブル側の「SQL*Net more data from dblink」が計上されています。

・Windows側のCPU負荷が計上されていない?
 Linux側ではSESSION_STATE=「ON CPU」が計上されていますが、Windows側ではあまり計上されていません。
 タスクマネージャのCPU使用率は90%と高負荷だったので、もっとSESSION_STATE=「ON CPU」が計上されても良い筈です。

V$ACTIVE_SESSION_HISTORYの1秒毎のサンプリングではWindows側のCPU負荷が計上されなかった為、SQLトレースを有効化して再確認しました。
TKPROFで整形して、最も負荷が掛かっていたSQLは、Linux、Windowsどちらも下記のSELECT文です。

BLinux CDB内 PDB間 TKPROF
SELECT T.INFO
FROM
 TESTTABLE@PDB T
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     10      0.00       0.00          0          0          0           0
Fetch      210     18.80      21.67          0          0          0    10000000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      221     18.80      21.67          0          0          0    10000000

@Windows CDB内 PDB間 TKPROF
SELECT T.INFO
FROM
 TESTTABLE@PDB T
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     10      0.00       0.00          0          0          0           0
Fetch      210     30.81      37.26          0          0          0    10000000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      221     30.81      37.27          0          0          0    10000000

SQLトレースでは、FETCHのCPU負荷が高い事が判りました。

@Windows CDB内 PDB間 実行時は、タスクマネージャでCPU使用率が90%近くまで上がりました。
仮想マシンには2CPU割り当てていたのですが、3CPUへ変更するとCPU使用率は60%まで下がったものの処理時間は変わりませんでした。
どうもマルチスレッドに対応していない処理がネックとなっている様な気がします。
2台(DB間)で動かすと分散実行されるので、1台(CDB内 PDB間)で動かすより速くなるのかも知れません。

遅い処理は見つけたものの、対策に結び付きませんでした。

 <4-3.更なる陰謀>

更に別の構成でも確認しました。
Windowsの同一マシン内にNon-CDBの別インスタンスを2つ作成し、Non-CDB間でdblinkした所、@Windows CDB内 PDB間 とほぼ同等の処理時間でした。
PDB間通信が遅いというより、同一マシン内でのDB間通信が遅い事になります。

同一マシン内でのDB間通信が遅いのならば、ループバック接続に問題があるのかも知れません。
PDB内に'127.0.0.1/[自service_name]'のdblinkを作成し、ローカルループバックアドレスのdblink経由でPL/SQLのBULK COLLECTを実行しました。
結果、Windows PDB内 ローカルループバック = @Windows CDB内 PDB間 とほぼ同等の処理時間となりました。
Linuxでも同様で、Linux PDB内 ローカルループバック = BLinux CDB内 PDB間 となりました。

構成


・仮説2「Windowsでのループバック接続が腐っている。MicrosoftかOracleの陰謀。」

ネットワーク帯域を調べる為、iperf2を使用しました。
iperf2では、TCP window sizeを変更すると、ネットワーク帯域が増減しました。
・Windows内ループバック、Windows→Windows、Linux内ループバック、Linux→Linuxでネットワーク帯域調査。
・iperfのサーバ側、クライアント側で、TCP window sizeを64Kから2048Kまで順次変更(Linux側では-wの設定値の2倍で実行される)。
・サーバ側: iperf -s -w 64-2048k
・クライアント側: iperf -c 192.168.x.y or 127.0.0.1 -w 64-2048k

結果(iperf2)
TCP window size (KB) Windows内ループバック Windows→Windows Linux内ループバック Linux→Linux
64 7.12 4.49 11.3 1.2
128 7.15 6.8 16.6 2.32
256 6.79 8.24 22 3.04
512 7.31 9.01 24 4.14
1024 7.4 8.39 23.7 4.73
2048 7.69 8.67 21.6 5.4

グラフ(iperf2)


・Linuxでは Linux内ループバック接続 >> Linux→Linux間通信。
・Windows→Windows間通信 >> Linux→Linux間通信。Hyper-V仮想ネットワークはWindowsの方が最適化されている。
・Windows→Windows間通信、Windows内ループバック、Linux内ループバックは TCP window size = 512KB で頭打ち。
・TCP window size <= 128KB では Windows内ループバック接続 > Windows→Windows間通信。
・TCP window size >= 256KB では Windows→Windows間通信 > Windows内ループバック接続 へ逆転。
・Windows内ループバック接続は、Linux内ループバック接続と比べて遅い。

iperf2の結果を見るとWindows内ループバック接続に問題がありそうな気配です。

Windows版のiperf2.0.5が32bit版だったので、64bit版のiperf3.0.11でも同様に確認しました。
バッファ長のデフォルト値がiperf2の8KBからiperf3では128KBへ変更されていた為、両方確認しました。
iperf3ではサーバ側のオプション設定が不可となっていました。
・サーバ側: iperf3 -s
・クライアント側: iperf3 -c 192.168.x.y or 127.0.0.1 -w 64-2048k (-l 8k)

結果(iperf3 8KB)
TCP window size (KB) Windows内ループバック Windows→Windows Linux内ループバック Linux→Linux
64 3.45 1.41 6.39 1.53
128 3.28 1.56 7.49 2.54
256 2.37 1.72 7.27 3.51
512 3.04 1.67 7.34 4.66
1024 2.17 1.63 7.51 5.09
2048 1.28 1.57 7.59 4.76

グラフ(iperf3 8KB)


結果(iperf3 128KB)
TCP window size (KB) Windows内ループバック Windows→Windows Linux内ループバック Linux→Linux
64 6.67 4.65 11.6 2.29
128 7.14 6.84 15.5 3.45
256 7.43 7.64 20 4.33
512 7.33 7.69 20.5 5.17
1024 7.29 6.74 19.4 6.3
2048 7.78 6.03 20.5 6.98

グラフ(iperf3 128KB)


・バッファ長8KBのiperf3はiperf2よりも遅い。
・iperf3でもLinux内ループバック接続が最速。
・iperf3ではWindows内ループバック > Windows→Windows間通信 の範囲が多い。

iperf3の結果を見るとWindows内ループバック接続はWindows→Windows間通信と比べると悪くは無さそうです。
アプリケーション側の使い方次第でWindows内ループバック接続は問題が発生するのかも知れません。
Microsoftの腐敗なのか、Oracleの陰謀なのか、真相まで辿り着けませんでした。

12cでは、THREADED_EXECUTION、DEDICATED_THROUGH_BROKER_listener-nameで、 Linuxでも一部プロセスをまとめてマルチスレッド化出来る様になりました。
マルチスレッド化でプロセス数が削減されると、プロセス自体のメモリ削減や、共有メモリ(SGA)のPage Table Entry使用量削減に効果があります。
Windowsではかなり昔のバージョンからoracle.exe内でマルチスレッド化しています。
その点では、WindowsはOracleのDB統合に向いているプラットフォームと言えなくもないです。
中にはHugePagesの事を知らずにLinuxでのDB統合を止めたベンダーもあったそうです。
しかし、Windowsではマシン内のDB間通信の遅さやCPU高負荷が問題となる事もありえそうです。

 <5.イベント資料>

Oracleに限りませんが、ベンダーが推している機能はベンダー自身が情報提供しています。
マルチテナントについても昨今のイベントで発表がありました。
資料によると、dblinkでの他システムへのアクセス性能を考慮して、本番環境ではスキーマ分割を採用したとの事でした。

Oracle DBA & Developer Days 2014
http://www.oracle.com/webfolder/technetwork/jp/ondemand/ddd2014/B1-4.pdf
事例から見えてきたマルチテナント・アーキテクチャとOracle Database 12c新機能の活用ポイント

Oracle CloudWorld Tokyo 2015
http://www.oracle.co.jp/campaign/cloudworld/download/pdf/S1-508.pdf
事例から見えてきたマルチテナント・アーキテクチャの活用ポイント

丁度本日2015/12/08から、品川でOracleのイベントが開催されます。
12.2の情報や事例紹介が楽しみです。

Oracle Cloud Days Tokyo
http://www.oracle.co.jp/events/clouddays/2015/

Oracle DBA & Developer Day 2015
http://www.oracle.co.jp/events/ddd2015/

 <6.まとめ>

・かなり昔のSQL*Netでも圧縮機能有。
・PL/SQLのBULK COLLECTはとても速い。
・WindowsでのPDB間通信(ループバック接続)は遅い。

明日はAyumu Shibataさんです。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2014年12月03日

[JPOUG Advent Calendar] Oracle on Hyper-V 2014

charade_oo4oと申します。昨年に引き続き、今年も「JPOUG Advent Calendar 2014」へ参加致します。
昨日はYohei Azekatsuさんの「fulltime.sh by Craig Shallahamer で DB CPU の内訳を調べる」でした。

今年もOracleとHyper-Vで何か書こうと思いましたが、2014年は昨年程の大きな動きは無かった様に思えます。
クラウド関連の動きは相変わらず活発ですが、オンプレミスでは、Microsoftの新OSはTecnical Preview止まり、Oracle Database 12cの小数点第3位は上がりましたが、Release2は再来年までお預けです。

新しいネタを用意出来そうも無かったので、古いネタを再料理しようと思います。
私自身は、2014年にもなって今更ながらに11gR2のParallel処理を活用し、Exadataを初めて使った年となりました。
学習用の11gR2 RACの環境はWindows7+VirtualBoxで構築していた為、RACについて何か調べる度にBootし直す必要がありました。
最近はWindows8.1+Hyper-Vで各種OS+DBを検証しているので、11gR2 RACもHyper-Vで再構築する事にしました。

 <目次>

・11gR2 RAC 仮想環境
・OL5 Version/Kernel
・変わるNIC
・共有ディスク
・遅いディスク
・膨れるディスク
・インストール時注意点
・インストール後注意点
・暴れるマウス
・クローンが無い
・重いネットワーク

 <11gR2 RAC 仮想環境>

11gR2 RACを仮想環境で構築する場合、OTNの資料が判り易いと思います。

http://www.oracle.com/technetwork/jp/database/database-11g/documentation/index.html
Oracle VM VirtualBox を用いた Oracle Real Application Clusters(RAC)11g Release 2 環境の構築
https://blogs.oracle.com/oracle4engineer/entry/material_rac_virtualbox
【チュートリアル】Oracle VM VirtualBoxを用いたOracle Real Application Clusters(RAC) 11g Release 2環境の構築

Windows7+VirtualBoxの仮想環境で、現在はOracle Linux 6.4(OL6.4)又は Oracle Linux 6.3(OL6.3)を使用する資料が公開されていました。
昔私が構築した際はOracle Linux 5.7(OL5.7)での資料が公開されていました。
ExadataやPlatinum実技試験等、今でもOL5の環境が必要となる事もあると思います。
今回のHyper-Vでの構築ではOL5を使用しました。

 <OL5 Version/Kernel>

Hyper-VでOL5を使用する場合、Linux Integration Services(LIS)を組込済のOL5.9以降が便利です。
LISがないと、低速なレガシネットワークアダプターしか認識せず、ホストOSとゲストOS間のマウス連携も働きません。
OL5.9以降ではRHEL互換KernelにはLISが組み込まれていますが、UEKでは未組込です。
その為、OL5.9以降(最新はOL5.11)でRHEL互換Kernelを使用した方が良いです。

OL6ではOL6.4以降(最新はOL6.6)で、RHEL互換Kernel/UELどちらもLISを組込済です。

VirtualBoxではなくHyper-Vを使用する利点として、Kernelアップデート後にGuest Additionsをインストールし 直す必要が無いという点が挙げられます。

 <変わるNIC>

Hyper-Vの仮想マシンのデフォルト設定では、前回起動時と異なるMACアドレスへ変更される場合があります。
LinuxではMACアドレス毎に新たなethとして認識されます。
MACアドレスが変わると、古いethに設定したIPアドレスは使われません。
IPアドレスが変わると、ゲストOS上に構築したRACが稼働不能となってしまいます。

対策として、仮想マシンの電源ON後に割り当てられたMACアドレスを静的に設定しました。
grubメッセージ表示中にすぐに電源OFFして、ネットワークアダプター → 高度な機能 → MACアドレス から、 動的 → 静的 へ変更しました。

Hyper-Vの仮想スイッチは、外部通信するNODE側のeth3用とDNS側のeth1用は「外部」、それ以外は「内部」で作成しました。
NODE側のeth1,2用のインターコネクトは「内部」ではなく「プライベート」を使用しても良いのですが、最後の方で記載する理由から止めました。

 <共有ディスク>

通常、RACを構築する際には、Fibre ChannelやiSCSI等の高価なSANストレージが必要です。
OTNのVirtualBox+11gR2 RACの資料、更に遡るとVMware+10gR2 RACの資料でも、RACの共有ディスクは仮想ディスクファイルの共有で低コストに実現していました。

Windows8.1(2012R2) Hyper-Vから、同様の仮想ハードディスクの共有が実装された為、当初はこの機能を使用する予定でした。
しかしこの機能はPC単体のディスクでは利用不可でした。
SCSIコントローラ → ハードドライブ → 高度な機能 → 仮想ハードディスクの共有 → 仮想ハードディスクの共有を有効にする のチェックを入れると、「仮想ハードディスクがある記憶域は、仮想ハードディスクの共有をサポートしていません。」というエラーが出てしまいます。
理由は下記の通りでした。
・Hyper-Vの仮想ハードディスクの共有には、スケールアウトファイルサーバーが必要。
・スケールアウトファイルサーバーには、SANストレージが必要。

対策として、今回はiSCSI S/Wを導入しました。
OTNのVirtualBox+11gR2 RACの資料は、NODE2台にDNS1台の構成です。
DNS側に「scsi-target-utils」をインストールして、iSCSI Targetとしました。
NODE側の「iscsi-initiator-utils」はOTN資料通りでインストール済でした。

共有ディスク/dev/sdb-sdg用のVHDXはiSCSI Target(DNS)側にのみ接続しました。
Hyper-Vの仮想マシン設定(第1世代)で、起動用ディスクはIDE、共有ディスクはSCSIで接続しました。
iSCSI Initiator(NODE)側は起動用ディスクのみです。

iSCSI用ネットワークとして、Hyper-Vの仮想スイッチと全仮想マシンでNICを1系統ずつ追加しました。
RAC用のインターコネクトで192.168.100.0/24と192.168.200.0/24が使用されていた為、被らない様にiSCSI用は192.168.101.0/24としました。

DNS用の仮想マシン、OL6版のOTN資料ではメモリ1024MBを指定していますが、OL5版では512MBでした。
iSCSI Target化した場合でも512MBでメモリ不足とはなりませんでした。

--iSCSI Target(DNS)側作業
yum install scsi-target-utils

#/etc/tgt/targets.conf 追記
<target iqn.2014-12.jp.oracle11g.dns1-iscsi-disk>
    backing-store /dev/sdb      # Becomes LUN 1
    backing-store /dev/sdc      # Becomes LUN 2
    backing-store /dev/sdd      # Becomes LUN 3
    backing-store /dev/sde      # Becomes LUN 4
    backing-store /dev/sdf      # Becomes LUN 5
    backing-store /dev/sdg      # Becomes LUN 6
    initiator-address 192.168.101.0/24
    write-cache off
</target>

#サービス再起動
service tgtd restart
chkconfig tgtd on

#設定確認
tgtadm --lld iscsi --op show --mode target

--iSCSI Initiator(NODE)側作業
#iscsi-initiator-utilsはインストール済

iscsiadm --mode discovery --type sendtargets --portal 192.168.101.254 --login
#/dev/sdb-sdgのマウント確認

 <遅いディスク>

2012/12/05に書いたネタ、ミスアライメントのLinux版です。
OL5はパーティション開始オフセットが31.5K(63セクタ)で作成される為、物理4Kセクタ(AFT)のHDDやSSDやRAIDでは速度低下します。Small Readは2倍、Small Writeは4倍、DISK I/O負荷が上がります。
OL6はパーティション開始オフセットが1M(2048セクタ)で作成される為、大抵の環境で問題ありません。

本来ならOL5でミスアライメントを解消する方法を見つけるべきなのでしょうが、今回は安直な手段をとりました。
1.まずOL6を最小インストール(パーティション作成)。
2.次にOL5でインストールし直し。パーティションの設定で「カスタムレイアウトを作成します。」を選択して、マウントポイント(/,/boot)とフォーマット(ext3,swap)を指定。

共有ディスク用にiSCSIでマウントした/dev/sdb-sdgでも、fdiskでミスアライメント対策しました。
fdisk /dev/sd<x>
u → n → p → 1 → 2048 → → w

全ディスク、全パーティションの開始位置が、fdisk -lu /dev/sd<x> で start 2048 や 1026048 の様に、物理セクタサイズやRAIDストライプサイズで割り切れれば対策完了です。

 <膨れるディスク>

OL5が採用しているファイルシステムext3は、容量可変VHDXファイルとの相性が悪いです。
大きなディスクをフォーマットしただけでも、ゲストOSでの使用量以上にVHDXファイルが膨れ上がってしまいます。
OTN資料のHDDサイズではそれ程大きな問題は発生しませんが、ディスクの無駄遣いに繋がります。

下記の回避策が一般的です。
・PowerShellからブロックサイズ1MB(デフォルト32MB)のVHDXを作成。
  New-VHD -Path node1.vhdx -Dynamic -SizeBytes 25GB -BlockSizeBytes 1MB
・VHDXではなくVHDを使用。AFT対応を考えると非推奨。

OL6が採用しているext4では、容量可変VHDXファイルでもそれ程肥大化しません。

 <インストール時注意点>

VirtualBoxと違い、Hyper-V向けにインストール時に設定変更した方が良い箇所があります。
OL5で設定方法が違う箇所についても記載します。

--OL5,OL6共通
・地域の設定 → システムクロックでUTCを使用 → チェック無。
・ソフトウェアのカスタマイズ → 仮想化 → HyperV → チェック有。

--OL5差分
・ネットワークデバイスの設定 → 編集 → Enable IPv6 support → チェック無。
・ソフトウェアのカスタマイズ oracle-rdbms-server-11gR2-preinstall → oracle-validated。
・ファイアウォール → 無効。
・SE Linux → 無効。

 <インストール後注意点>

OL5とOL6ではネットワーク関連の設定箇所が異なります。殆どGUIから設定可能です。
コマンドも一部変わっています。

・システム → 管理 → ネットワーク
  デバイス → eth<n> → 編集
   全般 → 一旦dhcpを選択 → 「DNS情報をプロバイダから自動取得 → チェック無。
      → 固定のIPアドレス設定 → 再設定。
  DNS → ホスト名 → node<n>.oracle11g.jp
    → 1番目のDNS → 192.168.56.254
    → DNS検索パス → oracle11g.jp
・oracle-rdbms-server-11gR2-preinstall-verify → oracle-validated-verify
・udevadm control --reload-rules → udevcontrol reload_rules

 <暴れるマウス>

OL5の起動後、マウスカーソルの動きに違和感があるかも知れません。

インストール時と同様、仮想マシンのコンソールをクリックしないとマウスカーソルが働かない場合、LISが働いていません。
UEKで起動しているかも知れませんので、/etc/grub.confを見直して再起動する必要があります。

OL5のRHEL互換Kernelでは、ホストOSとゲストOSのマウスカーソルが連動せずに過剰に動きます。
例えるなら、キャリブレーションされていないタッチパネルの様な状況で、非常に使い辛いです。

OL6ではマウスカーソルの問題はありませんが、ホストOSとゲストOS間のクリップボード連携が上手く働きません。

今回はHyper-Vの仮想コンソールを使う事を諦めて、リモートデスクトップソフトのVNCで操作する事にしました。
OL5ではOTN資料通りで「vnc-server」はインストール済だった為、設定のみ行いました。
OL6では「tigervnc-server」をインストールする必要があります。

#/etc/sysconfig/vncservers 追記
VNCSERVERS="2:oracle"
VNCSERVERARGS[2]="-geometry 1024x768"

#接続ユーザ毎に設定
vncpasswd

#サービス起動 設定ファイル作成
chkconfig vncserver on
service vncserver start

#~/.vnc/xstartup 変更
#xterm ...
#twm &
exec gnome-session

#サービス再起動 設定ファイル反映
service vncserver restart

ホストOSのvncviewerから「192.168.56.101:2」へ接続して、node1のoracleユーザのデスクトップを快適に操作可能です。
Javaの例外サイトリストに登録後、ブラウザから「http://192.168.56.101:5802」で接続する事も可能ですが、Nativeアプリの方が快適です。

要注意、vncでログアウトしてはいけません。

 <クローンが無い>

Hyper-Vでは、VirtualBoxの様な親切なクローン機能はありません。
おそらくSystem CenterでTemplate化する方針なのでしょう。
今回は「node1」の仮想ファイル一式をディレクトリ毎手動コピーした後、「仮想マシンのインポート」から「仮想マシンをコピーする(新しい一意なIDを作成する)」を実行しました。
その後、起動用ディスクのリネーム、NICの 静的 → 動的 → 静的 を手動実行しました。

 <重いネットワーク>

ゲストOSの準備が整えば、後はOTN資料通りに11gR2 RACを構築可能です。

但し、Hyper-Vで構築した11gR2 RACは妙に負荷が高く、Load Averageが20を超える事もありました。
同一物理マシンで構築したHyper-Vのスタンドアロンの11gR2や、VirtualBoxでの11gR2 RACはそこまで負荷は上がりません。
私自身が用意した環境ではないのですが、iSCSIを使用したVirtualBoxでのRAC環境も高負荷でした。
Hyper-Vの問題というより、iSCSI S/Wの問題の様です。

調べた所、iSCSIの高速化にジャンボフレーム化が有効という記事がありました。
最大フレームサイズを1.5Kから9Kへ拡大してスループットを向上します。
ジャンボフレーム化する為には、NIC、スイッチ、通信経路を全て対応する必要があります。
ゲストOS側では、eth<n>へMTU=9000を設定しました。
Hyper-Vの仮想スイッチでは、ホストOS側に追加された仮想化NICの「Hyper-V 仮想イーサネット アダプタ #n」のプロパティ → 詳細設定 → Jumbo Packet から、 無効 → 9014Bytes へ変更しました。

「内部」の仮想スイッチではホストOS側に仮想化NICが追加されるのですが、「プライベート」では仮想化NICが追加されません。
「プライベート」でのジャンボフレーム化の設定変更箇所が判らず、「内部」を使用しました。

更に、11gではOracle Netのパケットサイズが2Kから8Kへ変更されています。
その為、RAC用インターコネクトでもジャンボフレーム化は有効だと思います。
但し問題もあり、物理環境の通信経路の設定によっては8Kのパケットでは繋がらない場合もあるとの事です。
10g以前のClientからは繋がるのに、11g以降のClientからは繋がらない、そんな障害も起きる事があるそうです。

ジャンボフレーム化の効果を確認する為、RAC用共有ディスクとは別のLUNをDISK I/Oネックが発生しない様にRAMDISK上に用意して、ホストOS側のiSCSI Initiatorから接続して、CrystalDiskMarkで計測しました。
ジャンボフレームでは特にSequential Readのスコアが倍増しています。

iSCSI 通常フレーム iSCSI ジャンボフレーム
iscsi_ol5_normal iscsi_ol5_jumbo

但し、肝心の11gR2 RACの負荷は、ジャンボフレーム化でも殆ど下がりませんでした。

Oracle自身のI/O測定機能「DBMS_RESOURCE_MANAGER.CALIBRATE_IO」でも確認しました。
このCALIBRATE_IO、Enterprise Editionでは結構重要です。
11.2.0.2以降では、Parallel処理の「自動並列度(Auto DOP)」でCALIBRATE_IOの結果が使用されます。
11gR2(11.2.0.1)登場時に作成された資料では、CALIBRATE_IOの事に触れられていないかも知れません。
CALIBRATE_IOしていないと(RESOURCE_IO_CALIBRATE$が0行だと)、Auto DOPが働かず、Default DOPで実行されてしまいます。
例えば、In-Memory Parallel Executionで実行する為にSQLへPARALLEL(AUTO)ヒントを付けた際、テーブルサイズに関わらずDefault DOPの大量コア数でParallel処理されてしまいます。
Exadataでも同様です。

「DBMS_RESOURCE_MANAGER.CALIBRATE_IO」自身にも結構癖があります。
最初にHDD(SSHD)で試した時は、SSHDのSSD部に乗るのか、実行する度に速くなりました。
iSCSIのディスクをRAMDISKへ移動した後でも、複数回実行すると結果にかなりばらつきが出ました。
今回は5回計測した中間値(3位)で比較しました。

Hyper-V+11gR2 RACでは、iSCSIのディスクをRAMDISKへ移動して、通常フレームとジャンボフレームで比較しました。ジャンボフレームではLATENCYが向 上していますが、LATENCYはばらつきが特に大きく、本当に性能向上しているのか微妙です。
昔、OTN資料を基に作成したVirtualBox+11gR2(通常フレーム)でも、共有仮想ディスクファイルをRAMDISKへ移動して計測しました。IOPSは若干低いスコアでしたが、MBPSとLATENCYはネットワークを経由しない仮想SATAの恩恵か良好でした。
Hyper-V側に低いスコアが並んだので、スタンドアロンのASMの11gR2でも計測しました。iSCSIやRACでのネットワーク遅延が発生しない為、全項目最高スコアでした。


MAX_IOPS MAX_MBPS LATENCY
Hyper-V+11gR2 RAC 通常 14993 280 11
Hyper-V+11gR2 RAC ジャンボ 15646 277 7
VirtualBox+11gR2 RAC 10686 1134 0
Hyper-V+11gR2 ASM 48615 3415 0

RAMDISK上のVHDX自体は3GByte/s以上の帯域があります。
Hyper-Vの仮想化NICは10Gbps(=約1GByte/s)なので、RAMDISKの帯域を使い切れません。
OL5のiSCSIでは仮想化NICの10Gbpsの帯域の1/3も使えていませんでした。

iSCSIの問題かも知れないので、iSCSI以外のプロトコル、ファイル共有のSMB3.02も調査しました。
iSCSI TargetのゲストOSもWindows Server 2012R2へ変更し、ジャンボフレームを有効化し、iSCSI、SMB3.02、双方で使用するVHDXをRAMDISKへ格納して、CrystalDiskMarkで計測しました。
iSCSI Targetの特性は、OL5は4Kが良く、2012R2はSequentialが良好でした。2倍以上の差はなかったので、このH/W,S/Wでは iSCSIはこの位の性能なのでしょう。
SMB3.02は特にSequential Writeが良好でした。4K QD32は4K QD1と変わらなかったので、マルチタスクな処理は苦手なのかも知れません。

iSCSI 2012R2 SMB3.02 シングルチャネル
iscsi_2012r2 smb302_single

仮想化NICの帯域不足の問題なら、ゲストOSの仮想スイッチを2つに増やせば、Active/Activeで稼働するSMBマルチチャネルで更に速度改善出来るかも知れません。
しかし、CrystalDiskMarkのスコアはSMBマルチチャネルもシングルチャネルも殆ど変わりませんでした。
ホストOSのタスクマネージャから仮想スイッチの使用帯域を確認すると、SMBマルチチャネルはシングルチャネルでの上限値を2つのNICで分割した様な数値でした。
ホストCPUの負荷も高く、1コア分の90%近くを使用していました。SMBマルチチャネルのWriteでは別コアへオフロードされている様ですが、合計負荷はシングルチャネルと同様でした。

SMB3.02 マルチチャネル ネットワーク負荷 CPU負荷
smb302_multi task_net_smb task_cpu_smb

複数コアを使用するというReceive Side Scalingは、ホストOS、ゲストOS、共にデフォルトで有効となっており(netsh interface tcp show global)、ゲストOSのVirtual Receive Side Scalingも 無効 → 有効 へ変更してみたのですが、「内部」の仮想スイッチでホスト OSの1コアに負荷が掛かる傾向は変わりませんでした。
今回はネックとなっている箇所まで判りませんでしたが、CPUに負荷をかける仮想スイッチの限界を垣間見た様な気がします。

 <まとめ>

・11gR2 RAC、基本的にはOTN資料通りで大丈夫。
・Hyper-VでOL5ならRHEL互換Kernel。
・Hyper-VでLinuxなら静的MACアドレス。
・DNS1をiSCSI Target化。
・Linuxでもミスアライメントに要注意。
・VHDX作成はPowerShellで。
・OTN資料差分。
・VNCはログアウト禁止。
・Hyper-Vでは手動クローン。
・仮想スイッチは重い。iSCSI S/Wは更に重い。
・DBMS_RESOURCE_MANAGER.CALIBRATE_IOは重要。

明日は渡部亮太さんです。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2013年12月03日

[JPOUG Advent Calendar] Oracle on Hyper-V 2013

charade_oo4oと申します。昨年に引き続き、今年も「JPOUG Advent Calendar 2013」へ参加致します。今回もOracleとHyper-Vに関する話題です。
昨日はwrcsus4さんの「SQL*Plusで展開表示 - pr.sql from Tanel Poder's TPT scripts」でした。

 <2013年、OracleとHyper-V>

2013年のOracleとHyper-Vの動きを振り返ると、6月のクラウド分野での提携発表、9月のOracle OpenWorld 2013での基調講演、かなり進展がありました。
今ではMicrosoftのパブリッククラウドWindows Azureの仮想マシンギャラリーからOracle Databaseを選択可能です。

azure

 <Hyper-V、再検証環境>

昨年の「JPOUG Advent Calendar」にて、自分の投稿後の日程で公開されたblogを拝見して、1年越しに再検証したい点も出てきました。
1年経過した為、ホストOS、ゲストOS共にS/W環境を見直しました。

種別 OS bit DB
ゲストOS Windows Server 2012 Standard 64bit Oracle Database 11gR2 SEOne
ホストOS Windows 8.1 Enterprise 64bit

ターミナル・リリースの11.2.0.4にて2012がサポートされた為、ゲストOSを見直しました。まだ12cは検証途上です。
ホストOSは、サーバOS(2012R2)と同様の仮想化技術を使用するクライアントOS(8.1)を使用しました。クライアントOS向けのユーティリティを使用する為です。
H/W環境は変わらず、DISK I/OネックなHDDのNotePC(2コア4スレッド)です。

 <バルク処理、本当に有効?>

2012/12/10のakaganeerさんの「バルク・マージをやってみた。」を拝見して、バルク処理の有効性を確認したくなりました。ゲストOSのCPU割当数を検証する為の大量INSERTスクリプトにPL/SQLの単純ループ処理を使用していた為、バルク処理で速度改善出来ないかと思った次第です。
PL/SQL以外にSQLでのバルク処理(INSERT...SELECT文)も確認しました。2012/12/20のspitz2bassさんの「11gR2 再帰SQL」も試しましたが、WITH句ではsorts (memory)がレコード件数分発生してしまい性能が出なかった為、sorts (memory)が少なくて済んだ階層問い合わせ(CONNECT BY)を使用しました。
それぞれの処理概要は下記の通りです。

PL/SQL 単純ループ処理 PL/SQL バルク処理 SQL INSERT...SELECT文
FOR I IN 1..n
LOOP
  INSERT文;
END LOOP;
FORALL I IN 1..n
  INSERT文;
INSERT INTO "tablename" ( ... )
SELECT ... FROM DUAL
CONNECT BY LEVEL <= n;

まず、SQL*Plusで単独実行して、set timing onでの経過時間を比較しました。

単独実行
処理方法 処理時間
SQL INSERT...SELECT文 0:00:05.61
PL/SQL バルク処理 0:00:06.00
PL/SQL 単純ループ処理 0:00:14.76
sql_1

単独実行では、PL/SQL 単純ループ処理が最も遅く、PL/SQL バルク処理とSQL INSERT...SELECT文は2倍以上の処理速度でした。バルク処理は非常に有効だと思えます。

しかし、業務システムの本番環境では、複数の処理が同時実行される事も多いと思います。そこで、ゲストOS=2CPUのDISK I/OネックなHDD環境でINSERTスクリプトを多重実行しました。
ヒント「/*+ APPEND */」のダイレクト・パス・ロードでは表ロックがかかってしまい、多重実行ではなく連続的な単独実行となってしまうので、従来型・パス・ロードとしました。
PL/SQL バルク処理は若干遅かった為、SQL INSERT...SELECT文とPL/SQL 単純ループ処理を比較しました。

多重実行
処理方法 処理時間
SQL INSERT...SELECT文 0:01:29
PL/SQL 単純ループ処理 0:01:38
sql_n

単独実行では2倍以上の速度差が出ましたが、多重実行では10%程度しか差がありません。
単純ループ処理からバルク処理へ変更しても、DISK I/Oネックな環境ではあまり速度改善しない場合もあります。開発環境では効果有でも、本番環境ではさほど変わらず、そんな状況もありえるかも知れません。

StatspackのTop5待機イベントは下記の通りです。

SQL INSERT...SELECT文 2CPU(HDD): 処理時間=0:01:29
Event                 Waits Time
(s)
Avg
wait
(ms)
%Total
Call
Time
log buffer space 723 241 333 35.1
control file sequential read 1,196 88 74 12.9
log file parallel write 251 84 333 12.2
db file parallel write 1,455 71 48 10.3
log file sync 49 47 955 6.8

PL/SQL 単純ループ処理 2CPU(HDD): 処理時間=0:01:38
Event                 Waits Time
(s)
Avg
wait
(ms)
%Total
Call
Time
log buffer space 698 198 284 28.5
log file parallel write 445 83 187 12.0
CPU time
83
12.0
db file parallel write 1,377 68 49 9.7
db file sequential read 255 65 254 9.3

どちらの処理も「log buffer space」が1位です。昨年同様、log_bufferの拡大では速度改善せず、HDDがDISK I/Oネックとなっている様です。
PL/SQL 単純ループ処理では3位に「CPU time」がありますが、SQL INSERT...SELECT文では入っていません。タスクマネージャーでもCPUは低負荷でした。

 <SSD、DISK I/Oネック解消?>

2012/12/17のsh2ndさんの「Provisioned IOPSの検討 - JPOUG Advent Calendar 2012」を拝見して、SSDの採用でDISK I/Oネックを解消出来るのではないかと思いました。但し、大容量SSDの価格、フラッシュの書換寿命、懸念点を払拭出来ず未導入です。
そういえば、某ISV試験対策でVirtualBoxの仮想マシンを複数稼働させる為、NotePCのメモリを16GBへ拡張していました。最近は値上がりしている様ですが、購入当時はHDD並の価格でした。
メモリを8GB程度RAMDISK化して、そこにOracleのデータファイル一式を格納したVHDXファイルを置いて、SSD検証用に利用出来ないかと考えました。
サーバOS用のRAMDISKソフトが見つからなかった為、ホストOSはクライアントOS(8.1)としました。

まずはRAMDISK自体の性能確認で、ホストOSでのRAMDISK自体のドライブ、RAMDISKへ格納したVHDXファイルをホストOS自身でマウントしたドライブ、RAMDISKへ格納したVHDXファイルをゲストOS側から、それぞれCrystalDiskMarkで計測しました。

単独計測
ホストOS RAMDISK ホストOS VHDX ゲストOS VHDX
host_ram host_vhdx guest_vhdx

「ホストOS VHDX/ホストOS RAMDISK」の比率(VHDX化による性能劣化)は、最も良好なSequential Readでも0.8未満です。
「ゲストOS VHDX/ホストOS VHDX」の比率(Hyper-VのDISK処理による性能劣化)は、4K QD32以外では0.8-0.9なので、VHDX化による性能劣化の方が影響があります。
ホストOS VHDXでは、ベンチマーク実行時のCPU負荷高騰(冷却ファン回転数上昇)の影響で、最後に実行される4K QD32のスコアが低下していました。
ホストOS、ゲストOS共に、Fusion-io ioDrive2以上のスコアを叩き出しています。

次にOracleでの検証では、今回もPL/SQL 単純ループ処理のINSERTスクリプトを多重実行しました。ゲストOSのCPU割当数を1-4CPUへ変更して、HDD環境とSSD(RAMDISK)環境の双方での処理時間をグラフ化しました。
ゲストOS=2CPUのHDD環境でのStatspackのTop5待機イベントは上に記載済の為、2CPUのSSD環境のみ抜粋しました。1,3,4CPUでのStatspackは、昨年と似たような傾向だった為、割愛しました。

CPU割当数別処理時間
cpu_hdd_ssd

PL/SQL 単純ループ処理 2CPU(SSD): 処理時間=0:00:49
Event                 Waits Time
(s)
Avg
wait
(ms)
%Total
Call
Time
CPU time
89
38.9
resmgr:cpu quantum 247 55 223 24.0
buffer busy waits 12,390 19 2 8.4
db file parallel write 153 14 92 6.1
log file parallel write 950 12 13 5.3

昨年同様、DISK I/OネックなHDDでは、CPU割当数が多い程、処理時間が増えています。
対してSSDでは、CPU割当数が多い程、処理時間が減っています。CPUが使えれば使えるほど速度改善する様です。「CPU time」は2-4CPUで1位、1CPUで2位、「resmgr:cpu quantum」は1CPUで1位、2CPUで2位、3CPUで3位。CPUが高負荷な傾向です。

1CPUでの処理時間は、HDDでは0:01:32、SSDでは0:01:22。どちらの環境もCPUネックな為、DISK I/Oの影響が低く、ほぼ同等です。
2CPUでの「CPU time」は、HDDでは83秒、SSDでは89秒なので、ほぼ同等です。
HDD=>SSDでは、CPU負荷は変わらず、LGWRやDBWRでの待機が激減した為、結果的にDISK I/Oネック=>CPUネックとなった様ですが、処理時間自体は大幅に改善しています。

少し前に、HDDからFusion-io ioDrive2へリプレースしたOracleサーバを調査した事があるのですが、そこでも慢性的なDISK I/Oネックが完全解消していました。
Fusion-ioは数年前まで米国メーカーを中心に採用されていましたが、最近は国内メーカーでも採用が進んでいます。2012年末には富士通へioDrive2のOEMを開始しており、2013年には日立から「Fusion- ioを用いたサーバ高速化モデル」が発表されています。
近い将来、SATA Express、SCSI Express、NVM Express等の規格で、PCIeフラッシュは更に身近な技術となるかも知れません。

ExadataやOracle Database Appliance等のEngineered Systemsに限らず、DB処理能力不足をSSD等のH/Wの力で解決出来る、そんな時代が来ている様です。

 <ホスト/ゲスト、どちらが大事?>

2012/12/06のGo Watanabeさんの「Oracle VM Server のファイルコピーを考える」を拝見して、Hyper-Vでもホスト OSとゲストOSでのDISK I/O同時負荷の影響を確認したくなりました。
Hyper-VもXen同様、ゲストOS(子パーティション)でのDISK I/Oや外部NETWORK I/Oは、ホストOS(親パーティション)経由で担当しています。
そこで、DISK I/O性能に余裕があるRAMDISK環境で、ホストOSとゲストOSの双方でCrystalDiskMarkを同時に計測しました。片方のみで計測が実行されてしまうとそちらのスコアが上がってしまうので、計測ボタン毎に何度か再試行しています。

同時計測
ホストOS RAMDISK ゲストOS VHDX
para_host para_guest

ホストOS、ゲストOS共、Sequential Read Writeは単独計測と比べて半減しています。2つ同時なので、性能も半分になった様です。
しかし、同時に32命令実行する4K QD32は、ホストOS側は殆ど性能劣化していませんが、ゲストOS側は1/4以下まで落ち込んでいます。単独計測での1命令実行の4K(QD1)よりも低いスコアです。Small Random Read Writeが多重実行された場合、ホストOS側のDISK I/Oを優先している様です。

ホストOSとゲストOSの処理の優先度は、ある程度は制御可能です。
タスクマネージャー=>詳細=>優先度の設定(リアルタイム,高,通常以上,通常,通常以下,低)、又はDOSコマンドのSTARTのオプション(REALTIME,HIGH,ABOVENORMAL,NORMAL,BELOWNORMAL,LOW)で、プロセスの優先度を変更可能です。
ゲストOS側での優先度の設定変更は殆ど計測結果に影響しなかったのですが、ホストOS側でCrystalDiskMarkの優先度を変更するとゲストOS側の計測結果がかなり変わりました。
ホストOS:HIGHへ設定すると、ゲストOS側の4K QD32は1桁台まで落ち込みました。逆に、ホストOS:LOWへ設定すると、ゲストOS側の4K QD32は100以上となりました。
CPUのスケジューラ設定で、ホストOSとゲストOSの処理の優先度をある程度見直し出来ましたが、ゲストOS側がホストOS側の計測結果を上回る事は無く、ホストOS側のDISK I/O優先の傾向自体は変わりませんでした。

OS設定のプロセッサのスケジュール「プログラム」「バックグラウンドサービス」も影響する様ですが、バラつきが大きく計測毎に傾向が変わってしまいました。
クライアントOS(8.1)では「プログラム」が初期設定、サーバOS(2012R2)では「バックグラウンドサービス」が初期設定です。

ゲストOS側でDISK I/O性能が必要な場合、ホストOS側からSmall Random Read Writeが発生しない様にする必要がありそうです。ホストOS側からの大量なSmall Fileのバックアップは要注意です。

 <サイジング、そんなに沢山必要ですか?>

最近のx86サーバの売れ筋は、性能と価格のバランスが良好な2WAYサーバです。ExadataやOracle Database ApplianceでもE5-2600シリーズを2CPU搭載するモデルがあります。
また、最近のx86サーバではNUMA(Non-Uniform Memory Access)を採用しています。CPUにコントローラを内蔵して、メモリやPCIeカードと直接アクセスしています。NUMAには長所もありますが短所もあります。

 【NUMAの長所】
・同一NUMAノード内でのメモリやPCIeカードへのアクセスが速い。
・OS:2012やHyper-VはNUMAに対応。

 【NUMAの短所】
・NUMAノードを跨るリモートメモリやPCIeカードへのアクセスは遅い。
・片方のCPUが省電力機能でダウンクロックしている場合は更に遅い。
・Oracle Databaseは11gR2以降NUMA最適化機能を無効化。
・NUMAノードのメモリ搭載量を超える様な巨大なプロセス(DBのキャッシュ等)では、マシン全体では空きメモリがある場合でも、NUMAノード間でのリモートメモリアクセスをせずにスワップアウトする事がある(Swap Insanity)。

一昔前の32bitOSの頃は、搭載メモリの半分以上を1プロセスに割り当てる事も少なく、GbEやRAIDカード等のI/Fも低速でした。
しかし最近は大容量メモリ搭載が現実的で、高速なI/Fも増えています。その為、NUMAの短所が顕在化する危険性も増えています。
MySQLやFusion-ioの事例でも、NUMAの弊害を聞いた事があります。

回避策として、CPUを1つのみ搭載する(複数搭載しない)という方法があります。CPUが1つならNUMAノードも1つです。
最近はマルチコア化が進んでいるので、1CPUでも性能面の不安は低減しています。NECの垂直統合型システム「Data Platform for Oracle Database」でも1CPUモデルがあります。

CPUを複数搭載する場合、巨大な単独インスタンスではなく複数インスタンスに分割して、1プロセスのメモリ割当をNUMAノードのメモリ搭載量以下に抑える回避策もあります。
サイジングの参考にOracle Database Applianceのオンラインドキュメントを参照した所、最大規模のSGA割当量でもNUMAノードのメモリ搭載量以下に抑えていました(最大SGA:NUMAノードメモリの割合は、V1では48GB:48GB、X3-2では64GB:128GB)。
BIOS/UEFI設定やOS/Hypervisor設定でNUMAを無効化する回避策もありますが、最近のサーバ自体がNUMA推奨である事が多く、NUMAノード内より7-8割程遅いリモートメモリアクセスを基準とするのが良いか微妙です。
F1のタイヤ戦略に例えるなら、プライムで長いスティントをゆっくり走るか、オプションで短いスティントに分けて飛ばすかの違いです。

H/Wのサイジングで余裕を持って2CPUとするとNUMAの弊害に陥る危険性、HugePage非採用のLinuxで余裕を持ったメモリサイジングをするとメモリスワップに陥る危険性にも似ているかも知れません。

 <まとめ>

・DISK I/O負荷が高い環境では、バルク処理での改善効果が低い場合有。
・SSD等のH/Wの力でDB処理能力不足を解決する方法も有効。
・Hyper-VのゲストOSのDISK I/Oは、ホストOSでのSmall Random Read Writeの影響を受け易い。
・CPUやメモリのサイジングは程々に。多過ぎてもトラブルの原因となりえる。

明日はKeiji Odaさんです。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2012年12月05日

[JPOUG Advent Calendar] Oracle on Hyper-V

charade_oo4oと申します。縁あって「JPOUG Advent Calendar」( http://www.zusaar.com/event/456005 )へ参加する事となりました。まずは自己紹介を。
本業はRCレーサーですが、ペイドライバーです。昨年は中国代表としてアジア大会を戦いました。その経緯はメーカーのブログに掲載されています( http://www.kyosho.com/blog/rc/index.php?id=11050005 )。
スポンサー活動で民需系のSEもやっています。中小規模システムでの活動が多かった為、Oracle DatabaseはWindowsサーバで導入する事が多かったです。H/Wリプレース案件もあるので、oo4oは今でも現役です。
今回は、WindowsのDBサーバをHyper-Vで仮想化してリプレースする事を想定して、自前のNotePCで試行錯誤した内容について書きたいと思います。

 <Hyper-V、検証環境>

今回想定した移行前後のOS/DBのバージョンは、下記の通りです。
移行後のゲストOSは、用途に応じて複数検討しました。

移行 種別 OS bit DB
物理OS Windows Server 2003 Standard 32bit Oracle 9iR2 SE
ゲストOS1 Windows Server 2003 Standard 32bit Oracle 9iR2 SE
ゲストOS2 Windows Server 2008R2 Standard 64bit Oracle 11gR2 SEOne
ホストOS Windows Server 2012 Standard 64bit

現物を用意した訳ではないですが、移行前の構成には、メモリ4GBの物理サーバ上に構成した32bitの2003と、DBは9iR2 Standard Editionを想定しました。
移行後のゲストOS1は、単純なP2Vを想定してOS/DB共に移行前と同一バージョンです。
移行後のゲストOS2は、64bit化でより多くのメモリを活用可能とする為、OS/DBをバージョンアップします。x64のWindowsでは9iR2がサポートされないので11gR2で、OSは11gR2がサポートする2008R2で検証します。
ホストOSは、最新の仮想化技術を使用する為、2012で検証します。但し、一部比較の為に2008R2も使用しました。

これ以外に、「Oracle Database Appliance」の事前評価用にOracle Linux 5.8+11gR2 EEをHyper-V上に構築する手順も試行錯誤していたのですが、検証環境なら別マシンのVirtualBox上に構築した方が簡単確実だという事に気が付いてしまい、今回は見合わせました。

 <P2V、遅いディスク>

ゲストOS1の2003を評価した際、VHDフォーマットの仮想ディスクへの書き込みが妙に遅いという事がありました。
ディスク作成方法を色々と見直した所、同一物理ディスク上でも、書き込みが遅いVHDもあれば、物理ディスクと同等の速度が出るVHDもありました。
論より証拠で、E:に書き込みが遅いVHD、D:に物理ディスクと同等の速度が出るVHDでのベンチマーク結果を表示します。

disk_ng disk_ok

Sequential Read Writeは大差ないのですが、Random Write 512KBでは52%(21.43/41.18)、Random Write 4KBでは35%(0.348/0.988)まで低下しています。

原因はパーティション作成時のミスアライメントでした。
今回使用したNotePCのディスクは物理4Kセクタ(AFT)の7200rpmハイブリッドHDDだったので、2003でパーティションを作成してしまうと、パーティション開始オフセットが32,256byte(31.5K)となってしまい、物理ディスクのブロックとズレが生じてしまいます。
対策は、2008以降のホストOSの「コンピューターの管理」からディスク初期化(MBR)+パーティション作成して、パーティション開始オフセットを1,048,576byte(1M)としてから、2003以前のゲストOSで使用すれば大丈夫でした。
AFTへ対応したという2012のVHDXフォーマットでも、ミスアライメントによる速度低下は発生しました。

このミスアライメントについて、NetAppにとても解り易い解説がありました。

http://www.netapp.com/jp/communities/tech-ontap/tot-virtualization-entry8-1203-ja.html
古いゲストOSを使用する場合の落とし穴―「アライメントの重要性」についてご存じですか?

ミスアライメントはAFTのHDD以外でも、SSDや、RAIDのストライプサイズでも影響するとの事です。
つまり、2003以前の物理サーバでRAID-5は書き込みが遅いと言っていた一因にミスアライメントがあった可能性もある訳です。

 <V2V、新OSは大飯喰らい>

32bitOSには4GTという機能があります。4GTを使用しないデフォルト設定では、1プロセス=2GB以内の上限がある為、メモリを4GB搭載した場合でも有効活用出来ません。
「/3GB」を指定すると、カーネルモード領域に1GB、ユーザーモード領域に3GB割り当てられ、1プロセス=3GBまで拡大出来ます。例えばOracleではDB_CACHE_SIZEへ更にメモリを追加出来る様になります。
但し「/3GB」のみでは、Free System Page Table Entries(FSPTE)が不足する事が多く、OSの動作が不安定となる場合があります。
そこで「/3GB /USERVA=xxxx」で、ユーザーモード領域を2-3GBの間で調整します。

http://support.microsoft.com/kb/316739/ja
/userva スイッチと /3GB スイッチを使用してユーザー モード領域を 2 〜 3 GB の間でチューニングする方法

仮想化したゲストOSの利点となりますが、物理サーバ上に構築したOSと比べてリソース使用量が少ない為、より多くのメモリをユーザーモード領域へ割当可能です。
2012の登場前に2008R2で調査した際は、「/3GB」のみでも充分なFSPTEが確保可能でした。
2012で再評価した所、「/3GB」のみではFSPTEが不足気味で、「/3GB /USERVA=xxxx」で調整する必要がありました。

そこで今回、ホストOSを2008R2と2012で切り替え、ゲストOS1の2003のVHDを割り当てて比較しました。ちなみにホストOSの切替にはVHDブートを利用しています。
更に余談ですが、久々に2008R2をホストOSとして起動した所、ログイン画面が表示されず真っ黒な画面にマウスカーソルのみが表示されるという障害に見舞われました。
新規インストールし直しましたが、Hyper-Vを役割追加すると障害が再発。逆に当初のVHDへ戻して、bcdeditでhypervisorlaunchtype=Offに設定してHyper-Vを無効化すると、無事にログイン画面が表示される....
2008R2のHyper-Vの評価は断念かと思いましたが、大量のWindowsUpdateの適用後、bcdeditでhypervisorlaunchtype=Autoに設定してHyper-Vを有効化すると、今度は無事にログイン画面が表示されました。何かのパッチが解決してくれた様です。

ホストOS ゲストOSスイッチ FSPTE
2008R2 /3GB 35368
2012 /3GB 12800
2012 /3GB /USERVA=3000 31232

以上の様に、2012は2008R2と比べてリソース使用量が多い事が解ります。
V2V等でホストOSを2008R2から2012へ変更する場合、ゲストOSでは「/USERVA=xxxx」の調整後、OracleのSGA割当を見直す必要があります。
他にも、ストレージが高速化される場合、REDOログのサイズ見直しも必要となるかも知れません。

 <SEOne、11gR2での価値>

費用面で考えると、Standard Edition Oneは非常に魅力的だと思います。x86サーバではコア数に関わらず2ソケットまで使用可能の為、Hyper-V等の仮想化サーバ用にも適していると思います。
但し機能面で考えると、Enterprise Editionと各種オプションによる機能強化は、初期費用を上回る利点があるかも知れません。
SEOneでは何が出来ないのか、11gR2のEnterprise Managerの画面から再確認したいと思います。

em_seone

パフォーマンスタブが無効化されて使用不可能となっています。ADDM、ASH、SQL監視は勿論、セッションの検索すら使用できません。サードパーティ製品か、旧バージョンのスタンドアロン版を使用したくなります。
RBOの9iからCBOの11gへ移行する必要がある場合、上記機能やSQLチューニングが利用出来れば、移行時やその後の運用でも工数削減が可能です。
その価値は、EE+オプションとSEOneの価格差以上かも知れません。

 <CPU、そんなに沢山必要ですか?>

Hyper-Vではサポートされる仮想プロセッサ数がゲストOS毎に異なります。
2012のHyper-Vの情報は、執筆時点ではja-jp側には翻訳されていませんでした。

http://technet.microsoft.com/en-us/library/hh831531.aspx
Hyper-V Overview

2012のHyper-Vでは、ゲストOSが2008R2では64CPU、2003では2CPUまでサポートされます。2003でのサポート上限は、2008R2のHyper-Vの頃から変わっていません。

検証に使用したNotePCが2コア4スレッドなので、ゲストOS2の2008R2を、4CPU、2CPU、1CPUへ順に変更して、11gR2 SEOneに対して複数セッションから大量のINSERTを行う検証スクリプトを実行した所、CPU割当数によって処理時間やStatspackのTop5待機イベントが変わりました。

4CPU: 処理時間=0:02:23
Event Waits Time (s) wait (ms) Call Time
log buffer space 315 306 971 25.9
CPU time   145   12.3
db file sequential read 368 142 387 12.0
log file parallel write 346 122 354 10.4
db file parallel write 1,693 121 71 10.2

2CPU: 処理時間=0:02:11
Event Waits Time (s) wait (ms) Call Time
log buffer space 290 296 1020 26.4
db file sequential read 643 126 196 11.3
log file parallel write 339 113 332 10.1
CPU time   107   9.5
db file parallel write 1,324 103 78 9.2

1CPU: 処理時間=0:02:00
Event Waits Time (s) wait (ms) Call Time
resmgr:cpu quantum 262 278 1059 34.1
CPU time   102   12.5
db file sequential read 699 75 107 9.2
log file parallel write 804 70 87 8.6
db file parallel write 297 66 223 8.2

4,2CPUでは「log buffer space」が多発していた為、log_buffer=64Mへの拡大も試したのですが、むしろ処理時間が増加したので32Mへ戻して計測しました。log_bufferのサイズ以外に原因がある様です。
処理時間を比較すると、1CPUが最も速く完了しています。
1CPUのみ「resmgr:cpu quantum」が多発してCPUの割当を待機しているので、1CPUでは割当が不足しているのかも知れません。
4,2CPUの待機イベントは似たような傾向で、4CPUの方が全体的に待機時間が増えています。
4,2,1CPU全てで「CPU time」は最上位ではなく、4,2CPUではLGWRやDISK I/O関連が上位に来ています。また「CPU time」はCPU割当数が多い程、待機時間が増加しています。

以上の事象から考察すると、大量書込のワークロードでは遅いHDDがI/Oネックとなっていて、2CPU以上に追加しても待機時間が増えるだけの状態なのだと思います。
処理実行中のDISKのアクセスランプとタスクマネージャーのCPU使用率も、4,2CPUではDISKの負荷が高く、1CPUではCPU使用率が高い状況でし た。
本格的な仮想化サーバでは速いストレージを用意すると思いますが、今回のNotePCでの検証は、足回りの能力を超えるエンジンを搭載しても、それを生かすどころか逆効果となりかねない実例だと思います。
そもそもSEOneはシリアル実行のみでパラレル実行は出来ないので、CPUを多く割り当てる必要性は低いかも知れません。

 <まとめ>

・P2V以外でも、ミスアライメントに要注意。
・仮想化テクノロジーが変わると、ゲストOS側にも手を入れる必要有。
・SEOne、初期費用はお買い得でも、運用を考えると割高?
・CPU割当数は、ストレージ性能とバランスさせる必要有。

明日はGo Watanabeさんへバトンが続いていきます。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2011年03月27日

川崎 オーストラリアGP

F1有志のウレタン走行会に参加。
最初はF:30を使用していたが、フロントが強かったのでF:40へ変更。
マクラーレンではリアサスのストロークが取れない。リアサススペーサーを外す。
主にピッチングを中心に変更。柔らかいロール赤は入口で曲がる。若干高速域で不安定か。
固い黄ではスペーサーを減らすとバランスが良い。
トラブルも多発。バンパー破損によるアンダー。トラクションコントロールデフの脱臼。
n.i.a.に揉まれたGPだった。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2011年03月26日

美女木 練習走行

震災以来、初めての車移動。N6、VOLCANOは昨年以来。
ピッチングを変更した際の挙動変化を見る。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2011年03月21日

ARS 練習走行

2年弱振りのARS。営業最終日。
F:30では巻き気味なのでF:40を使用。R:20は両面テープを入れたタイヤの方が喰っていた。
カーボンでは動き過ぎて高速域で不安定。FRPの方がまし。
高速サーキットなのでマシンのダメージが大きかった。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2011年03月20日

水天宮 練習走行

初めはスポンジで走らせていたが、ゴムの方が反応と転がりが良い。
再度スポンジに戻すと、スポンジの方が安定感がある。F:30では曲がり辛いのでF:20を使用。
6T&20inchから8T&18inchへ変更すると、速度域が向上。
フロントサスもいじる。0.5mmのスペーサーを入れてリバウンドを稼ぐとF:30でも曲がる様になる。
再度スペーサーを外してテンションをかけると、今度は1コーナー等の高速域からの飛び込みで巻く様になる。
キャンバーを付けないと安定感はあるが曲がらない。再度キャンバーを付ける。
スプリングを柔らかい銀へ変更すると落ち着く。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2011年03月19日

MRW 練習走行

久々のカーペット。F:30,R:20で走り始めたがリアが巻き気味。
リアタイヤをテープ有無でいくつか変えたが解決せず。
F:40では巻きはしないが新品近い溝量でないと曲がらない。

posted by charade at 00:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする