Oracle 仮想/物理サーバでの処理時間を比較する

 2015.09.01  株式会社システムインテグレータ

仮想サーバ上でのデータベース管理は様々なメリットがあるが

仮想サーバを利用することで、「コスト削減が見込める」、「リソース管理が適切に行えるようになる」など、様々なメリットを享受することができます。そのため、データベースの管理も例に漏れず仮想サーバを利用している企業も多いことでしょう。

では、仮想サーバでデータベースを管理すると、パフォーマンス面はどうでしょう。リソース管理を適切に行うことで、物理サーバと遜色ないパフォーマンスを期待できるのか。または大量アクセスによりメモリが頻繁に確保/開放されることでパフォーマンスが悪化してしまうのか。DBに限らず仮想サーバでの性能は、一般的には物理サーバ上のリソースとの対応付けが別途発生するなどの理由で、仮想サーバの方が性能劣化するといわれているようです。

今回は「仮想サーバと物理サーバではパフォーマンスにどれくらいの違いが出るのか」を検証していきます。

disp_201509_1_img_1.png

図1:検証イメージ

サーバの仮想化と性能に関して

一旦データベースに関わらず、サーバの仮想化と性能の関係について考えておきます。

先にも述べましたが、一般的には物理サーバよりも仮想サーバの方が、性能が劣化するといわれています。その理由の一つがI/Oの共有にあると言われています。仮想環境ではCPUやメモリーと共に、I/Oも複数の仮想サーバで共有します。そのため、CPUやメモリーに十分な性能が望めたとしても、I/Oの影響で物理サーバより性能が劣化するケースがあるようです。

データベースのI/Oに関して

では、データベースのI/Oはどうでしょうか。 今回検証対象としているOracleデータベースは、一般的にI/O負荷が高いソフトウェアと言われています。 代表的なものとしては、以下のファイルに様々なI/Oが発生します。

ファイル I/O発生処理
オンラインREDOログファイル LGWRプロセスでログバッファからのシーケンシャル書込が行われます。アーカイブログ・モードの場合、アーカイブREDOログファイルへ出力するため、シーケンシャル読込も行われます。
制御ファイル データベースの起動時に読込が行われ、情報の変更が行われた時に書込が行われます。
アーカイブREDOログファイル アーカイブログ・モードの時にARCHプロセスでオンラインREDOログファイルからのシーケンシャル書込みを行います。
データファイル 全タイプのI/O(シーケンシャル読込・書込み、ランダム読込・書込)が行われます。読込はサーバープロセスによって行われ、書込はサーバープロセスとDBWRプロセスによって行われます。

やはりデータファイルのI/Oが多く発生するようです。
今回の検証でも、このデータファイルにI/Oが発生するような検証を行っていこうと思います。

[RELATED_POSTS]

検証内容

今回はデータファイルへのI/Oを多く発生させるため、データの作成を大量に発生させて確認を行います。
検証方法としては、適当なテーブルに大量データを作成した実行時間を計測します。

検証詳細

・サーバの仮想化システムにはHyper-Vを使用 (サーバ構成は検証環境を参照)
・サンプルテーブルに100万件のデータを作成
・それぞれデータ生成終了までの時間を計測
・それぞれ5回実施し、平均を採用する
・一回の検証ごとにテーブルデータを削除し、DBバッファキャッシュをクリア
・データ生成には OBのデータ生成機能を使用
・コミット回数は1000回毎(第1回参照)

検証環境

今回の検証環境は以下の通りです。

マシン 物理/仮想 物理サーバ 仮想サーバ
OS Windows7 Windows7
CPU Intel Core i5-2430M 2.40GHz Intel Xeon 3065 2.33Ghz
メモリ 4.00GB 4.00GB
その他 プロセッサ数「4」 プロセッサ数「2」
DB 対象RDBMS Oracle11.0.2.0.1.0
テーブル名 TEST_VIRTUAL
テーブル項目
COL1 NUMBER(10)
COL2 NUMBER(10)

※主キー設定:なし

その他 初期化パラメータ「CPU_COUNT」=2
※プロセッサ数を合わせるため

 

データ生成に関して

今回生成するデータの内容は以下の通りです。
※データ生成の利用方法は第1回を参照。(第1回参照)

データベース開発に関するお役立ち資料

カラム名 データ生成方法
COL1 連番。1から開始し1ずつカウントアップ
COL2 乱数値(数値)

また、「SI Object Browser for Oracle Ver.13」より、データ生成機能が強化されました。
実行速度が向上しており、さらに実行結果見やすくなっております。

disp_201509_1_img_2.png

図2.データ生成実行結果

上記のように実行時間が表示されるようになりました。
データ生成機能を性能試験にもご利用いただけるような機能となっております。
さあ、この機能を使って実行時間を検証していきましょう。

検証結果

検証結果は以下の通りとなりました。

サーバ 1回目 2回目 3回目 4回目 5回目 平均
物理 00:23.323 00:30.467 00:33.820 00:31.548 00:27.692 00:29.370
仮想 00:56.795 00:55.812 00:53.280 00:52.750 00:56.218 00:54.971

※単位:秒

平均値での実行時間の対比は以下の通りです。

disp_201509_1_img_3.png

「物理サーバ」に比べ、「仮想サーバ」の方が2倍近く実行時間がかかっています。

追加検証

今回は検証を追加し、仮想サーバの特性を生かして、リソースの配分を変えながら検証します。
結果は以下の通りとなりました。

【CPUを変更】

サーバ 1回目 2回目 3回目 4回目 5回目 平均
仮想(CPU:1) 01:14.764 01:15.155 00:55.796 01:00.750 01:05.520 01:06.397
仮想(CPU:2) 00:56.795 00:55.812 00:53.280 00:52.750 00:56.218 00:54.971

※単位:秒

平均値での実行時間の対比は以下の通りです。

disp_201509_1_img_4.png

CPUの数を減らすことで、パフォーマンスの劣化も確認できました。

【メモリを変更】

サーバ 1回目 2回目 3回目 4回目 5回目 平均
仮想(メモリ:1GB) 01:01.781 00:59.298 00:57.650 00:58.441 00:56.171 00:58.668
仮想(メモリ:2GB) 00:56.126 00:58.195 00:59.455 00:58.650 00:59.693 00:58.424
仮想(メモリ:3GB) 00:54.969 00:57.765 00:58.140 00:55.770 00:57.177 00:56.764
仮想(メモリ:4GB) 00:56.795 00:55.812 00:53.280 00:52.750 00:56.218 00:54.971
仮想(メモリ:5GB) 00:52.781 00:50.531 00:50.171 00:51.151 00:52.701 00:51.467

※単位:秒

平均値での実行時間の対比は以下の通りです。

disp_201509_1_img_5.png

こちらも同様にメモリを増やした方が性能は良くなるようですが、それほどの差は見られないようです。

結論

今回の検証結果では、以下のようになりました。
・データの挿入処理では、物理環境より仮想環境の方か性能が劣化する
・仮想環境のリソース(CPU)の配分はパフォーマンスに影響する
・仮想環境のリソース(メモリ)の配分はパフォーマンスへの影響は少ない

今回の検証では、データ挿入処理における仮想環境の性能劣化が確認できました。
データの内容、件数、処理内容などによっては結果が異なるかと思われますが、今回の検証結果では物理サーバと仮想サーバで2倍近くの差が確認できたことから、DBを仮想環境で管理する際にはパフォーマンスの検証は非常に重要であることがわかりました。

また、仮想環境のリソース配分に関しては、CPUの影響を大きく受けるが、メモリの影響はあまり受けないということが確認できました。
今回の検証ではその他の仮想環境を平行で動かしていないため、もし多数の仮想環境を動かす場合は、さらに物理サーバとの性能差が顕著に現れてくるものと考えられます。

今回の検証結果は以上となります。
仮想環境でのDB管理を検討の際は、少しでも参考にしていただければ幸いです。

 

 

 

新規CTA

RECENT POST「DBlab」の最新記事


この記事が気に入ったらいいねしよう!
OBトライアル
ブログ購読のお申込み

RANKING人気資料ランキング

RANKING人気記事ランキング

RECENT POST 最新記事