仮想サーバ上でのデータベース管理は様々なメリットがあるが
仮想サーバを利用することで、「コスト削減が見込める」、「リソース管理が適切に行えるようになる」など、様々なメリットを享受することができます。そのため、データベースの管理も例に漏れず仮想サーバを利用している企業も多いことでしょう。
では、仮想サーバでデータベースを管理すると、パフォーマンス面はどうでしょう。リソース管理を適切に行うことで、物理サーバと遜色ないパフォーマンスを期待できるのか。または大量アクセスによりメモリが頻繁に確保/開放されることでパフォーマンスが悪化してしまうのか。DBに限らず仮想サーバでの性能は、一般的には物理サーバ上のリソースとの対応付けが別途発生するなどの理由で、仮想サーバの方が性能劣化するといわれているようです。
今回は「仮想サーバと物理サーバではパフォーマンスにどれくらいの違いが出るのか」を検証していきます。
図１：検証イメージ
サーバの仮想化と性能に関して
一旦データベースに関わらず、サーバの仮想化と性能の関係について考えておきます。
先にも述べましたが、一般的には物理サーバよりも仮想サーバの方が、性能が劣化するといわれています。その理由の一つが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が発生するような検証を行っていこうと思います。
検証内容
今回はデータファイルへのI/Oを多く発生させるため、データの作成を大量に発生させて確認を行います。
検証方法としては、適当なテーブルに大量データを作成した実行時間を計測します。
検証詳細
・サーバの仮想化システムにはHyper-Vを使用 (サーバ構成は検証環境を参照)
・サンプルテーブルに100万件のデータを作成
・それぞれデータ生成終了までの時間を計測
・それぞれ5回実施し、平均を採用する
・一回の検証ごとにテーブルデータを削除し、DBバッファキャッシュをクリア
・データ生成には OBのデータ生成機能を使用
・コミット回数は1000回毎(第１回参照)
検証環境
今回の検証環境は以下の通りです。
| マシン | 物理/仮想 | 物理サーバ | 仮想サーバ | |||
| 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 | |||||
| テーブル項目 |
※主キー設定：なし |
|||||
| その他 | 初期化パラメータ「CPU_COUNT」=2 ※プロセッサ数を合わせるため |
|||||
データ生成に関して
今回生成するデータの内容は以下の通りです。
※データ生成の利用方法は第１回を参照。(第１回参照)
| カラム名 | データ生成方法 |
|---|---|
| COL1 | 連番。1から開始し1ずつカウントアップ |
| COL2 | 乱数値(数値) |
また、「SI Object Browser for Oracle Ver.13」より、データ生成機能が強化されました。
実行速度が向上しており、さらに実行結果見やすくなっております。
図２．データ生成実行結果
上記のように実行時間が表示されるようになりました。
データ生成機能を性能試験にもご利用いただけるような機能となっております。
さあ、この機能を使って実行時間を検証していきましょう。
検証結果
検証結果は以下の通りとなりました。
| サーバ | １回目 | ２回目 | ３回目 | ４回目 | ５回目 | 平均 |
|---|---|---|---|---|---|---|
| 物理 | 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 |
※単位：秒
平均値での実行時間の対比は以下の通りです。
「物理サーバ」に比べ、「仮想サーバ」の方が２倍近く実行時間がかかっています。
追加検証
今回は検証を追加し、仮想サーバの特性を生かして、リソースの配分を変えながら検証します。
結果は以下の通りとなりました。
【CPUを変更】
| サーバ | １回目 | ２回目 | ３回目 | ４回目 | ５回目 | 平均 |
|---|---|---|---|---|---|---|
| 仮想(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 |
※単位：秒
平均値での実行時間の対比は以下の通りです。
CPUの数を減らすことで、パフォーマンスの劣化も確認できました。
【メモリを変更】
| サーバ | １回目 | ２回目 | ３回目 | ４回目 | ５回目 | 平均 |
|---|---|---|---|---|---|---|
| 仮想(メモリ：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 |
※単位：秒
平均値での実行時間の対比は以下の通りです。
こちらも同様にメモリを増やした方が性能は良くなるようですが、それほどの差は見られないようです。
結論
今回の検証結果では、以下のようになりました。
・データの挿入処理では、物理環境より仮想環境の方か性能が劣化する
・仮想環境のリソース(CPU)の配分はパフォーマンスに影響する
・仮想環境のリソース(メモリ)の配分はパフォーマンスへの影響は少ない
今回の検証では、データ挿入処理における仮想環境の性能劣化が確認できました。
データの内容、件数、処理内容などによっては結果が異なるかと思われますが、今回の検証結果では物理サーバと仮想サーバで２倍近くの差が確認できたことから、DBを仮想環境で管理する際にはパフォーマンスの検証は非常に重要であることがわかりました。
また、仮想環境のリソース配分に関しては、CPUの影響を大きく受けるが、メモリの影響はあまり受けないということが確認できました。
今回の検証ではその他の仮想環境を平行で動かしていないため、もし多数の仮想環境を動かす場合は、さらに物理サーバとの性能差が顕著に現れてくるものと考えられます。
今回の検証結果は以上となります。
仮想環境でのDB管理を検討の際は、少しでも参考にしていただければ幸いです。