|
||||||||||||||||||||
| 前のページ 1 2 3 4 | ||||||||||||||||||||
| 測定に至るまでに発生したトラブル | ||||||||||||||||||||
|
OSDL DBT-1は、ソースだけでなく実行結果もOSDL-Jのサイトにて公開されている。また、SAP DBからMaxDBに変更するにあたり、SQL構文上の違いはなかった。しかしMaxDBで動作させるためには、いくつかの修正を必要とした。それをまとめたのが表3である。 |
||||||||||||||||||||
表3:MaxDB対応への修正 |
||||||||||||||||||||
| 評価結果 | ||||||||||||||||||||
|
評価は、DBパラメータがデフォルトの状態とチューニングした状態の2種類と、カーネルバージョン2.4系(2ディストリビューション)と2.6系(1ディストリビューション)の組み合わせで実施した。これらの結果について、代表的な例を以下に記述する。 |
||||||||||||||||||||
| DBパラメータの効果 | ||||||||||||||||||||
|
RDBMSの種類にもよるが、デフォルトで設定されているパラメータは、多岐多様なシステムで稼働させるため、なるべくリソースを消費しないような値にしている場合がある。MaxDBもデフォルトではリソースを消費しない設定となっている。それだけに、チューニング効果は非常に大きいものとなる。 MaxDBとappServer間の接続数を拡張すると、多くのインタラクション応答時間で30%程度のレスポンス向上が見られた一方で、3倍以上遅くなるインタラクションもあった。最終的には他のパラメータも拡張することで、チューニング前の値まで戻す事ができた。 MaxDBのキャッシュは、デフォルトサイズ(80MB)でも90%弱のヒット率を示したが、拡張後(400MB)は90%半ばまで上がる事が確認できた。この差自体は小さく見えるかもしれないが、1SQLあたりのI/O数が半分近く下がっていることがMaxDBのログから読み取れ、実際には非常に効果があることがわかる。 MaxDBでは、データボリュームを分割することでパフォーマンスを向上させる事が可能であるが、今回の構成(DISK2台によるRAID0)では効果はなかった。 図2は、チューニング前後の仮想ユーザ数別BT/秒をグラフ化したものである。仮想ユーザは1200で頭打ちとなっている。このときのCPU消費率が90%以上となっていたためこの値が限界と思われるが、DISKをRAID0構成としたため、若干のオーバーヘッドがあると考えられる。余裕があれば追加調査を実施したいところ。 ![]() 図2:仮想ユーザ別BT/秒の推移 ![]() 図3:インタラクション応答時間 |
||||||||||||||||||||
| Linuxカーネル2.4と2.6の比較結果 | ||||||||||||||||||||
|
図4は、カーネル2.4と2.6の比較である。高負荷になるほど差が顕著に現れることがわかる。今回の評価では、グラフまでは掲載していないが、カーネル2.6では1800仮想ユーザまで計測を行った。グラフの伸びはほとんど見られなかったが、きれいな曲線となった。カーネル2.4では1000を超えると急に伸びが停滞する不安定な面が見られた。 ![]() 図4:カーネルバージョン比較 |
||||||||||||||||||||
| しかし昨今のプレス発表から、カーネル2.6ベースのシステムが主流となりつつあるので、今後新規に構築するシステムではさほど心配する必要はないのかもしれない。 |
||||||||||||||||||||
| OSDL DBT-1(MaxDB版)のまとめ | ||||||||||||||||||||
|
今回のDBT-1によるMaxDBの評価では、まずSAP DBに関するメンテナンスが中断されていた状態のDBT-1を最新版であるMaxDBに対応させた。今後は、ストアドプロシージャを使用しないSQLによるDBアクセスを実装することで、より汎用性の高い有用なプロダクトに育てる事ができるであろうとの結論に達した。 |
||||||||||||||||||||
|
前のページ 1 2 3 4 |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||




