WebLogic Server
パフォーマンス チューニング ガイド
データベースのチューニング
データベースがエンタープライズ レベルのボトルネックになる可能性もあります。データベースの最適なパフォーマンスを実現するには、この節のチューニング ガイドラインと、使用しているデータベースの製品マニュアルのチューニング ガイドラインに従ってください。
一般的な推奨事項
この節では、データベースのチューニングに関する全般的な推奨事項を示します。
優れたデータベース設計 - データベースの負荷を複数のディスクに分散して、ディスクへの過負荷ができるだけ発生しないようにします。また、テーブル、インデックス、およびログのサイズや構成を適切に設定することも重要です。 ディスクの I/O の最適化 - ディスクの I/O の最適化は、スループットとスケーラビリティに直接影響します。最高速のディスクへのアクセスでも、メモリへのアクセスに比べると大幅に時間がかかります。ディスクへのアクセス数は、可能なかぎり最適化する必要があります。通常は、I/O に使用するブロックやバッファのサイズを大きくするとディスクへのアクセス数が減り、負荷の大きいプロダクション環境でのスループットがかなり改善します。 チェックポイント - チェックポイント メカニズムでは、すべての不要なキャッシュ データを定期的にディスクにフラッシュ (クリーン アップ) することで、チェックポイントの期間の I/O アクティビティおよびシステム リソースの利用状況を改善します。チェックポイントの間隔を狭めると、ディスク上のデータの一貫性は保持されますが、データベースのパフォーマンスは低下します。チェックポイント メカニズムはほとんどのデータベース システムに備わっていますが、ユーザ レベルの制御が許可されていないデータベース システムもあります。たとえば、Oracle の場合、管理者はチェックポイントの間隔を設定できますが、ユーザが SQLServer 7.x チェックポイントを制御することはできません。推奨設定については、使用しているデータベースの製品マニュアルを参照してください。 ディスクおよびデータベースのオーバーヘッドは、複数の処理をバッチとしてまとめるか、並行して実行される処理の数を増やす (同時実行性を高める) ことによって、大幅に削減できる場合もあります。次に例を示します。
メッセージング ブリッジの BatchSize、またはストア アンド フォワードの WindowSize の値を増やすと、パフォーマンスが向上する場合がある。これは、バッチ サイズを大きくすると、I/O の数は減るが、サイズが増えるためです。 プログラム的に JDBC のバッチ API を利用する。 MDB トランザクション バッチ機能を使用する。「メッセージ駆動型 Bean のチューニング」を参照してください。 max-beans-in-free-pool および MDB のスレッド プール サイズを増やす (またはバッチを利用できる場合は減らす) ことによって、同時実行性を高める。
データベース固有のチューニング
この節では、Oracle、SQL Server、および Sybase のチューニングに関する基本的な推奨事項を示します。
| 注意: |
各データベースのベンダが提供するマニュアルのチューニング ガイドラインも必ず確認してください。 |
Oracle
この節では、Oracle のパフォーマンスのチューニングについて説明します。
プロセス数 - ほとんどのオペレーティング システムでは、Oracle サーバへの接続ごとにシャドウ プロセスを生成して接続をサービスします。したがって、Oracle で使用できるプロセスの最大数は、同時に処理できるユーザの数と、Oracle サーバが使用するバックグラウンド プロセスの数をカバーできる値に設定しなければなりません。通常、デフォルトの最大数では、並行処理するオペレーションの数が多いシステムには対応できません。プラットフォーム固有の問題については、Oracle の管理者ガイドを参照してください。このパラメータの現在の設定値は、次のクエリを使用して取得できます。 バッファ プール サイズ - バッファ プールは、Oracle サーバの SGA (system global area) の最も大きな部分です。これは、Oracle サーバがディスクから読み込んだデータをキャッシュする場所です。read-mostly アプリケーションの場合、データベースのパフォーマンスに影響する最も重要な統計は、バッファ キャッシュ ヒット率です。バッファ プールのサイズは、キャッシュ ヒット率が 95% 以上になる程度に大きくする必要があります。バッファ プールのサイズは、init.ora ファイルの db_cache_size パラメータの値 (データベース ブロック数) を変更して設定します。 共有プール サイズ - 共有プールは、Oracle サーバの SGA (system global area) の重要な部分です。SGA は、Oracle データベース インスタンスのデータおよび制御情報を格納する共有メモリのグループです。複数のユーザが同時に同じインスタンスに接続した場合、これらのユーザはそのインスタンスの SGA のデータを共有します。SGA の共有プール部分には、2 つの主な領域 (ライブラリ キャッシュとディクショナリ キャッシュ) のデータがキャッシュされます。ライブラリ キャッシュには、SQL 関連の情報と制御構造 (解析済みの SQL 文、ロックなど) が格納されます。ディクショナリ キャッシュには、SQL の処理に必要なメタデータが格納されます。
ほとんどのアプリケーションでは、共有プール サイズが Oracle のパフォーマンスに大きく影響します。共有プールが小さすぎると、限られた大きさの空間を管理するためだけにサーバのリソースが消費されてしまいます。これにより CPU リソースが消費され、複数のキャッシュの並行管理に制限のある Oracle では競合が発生する原因となります。トリガやストアド プロシージャを数多く使用すると、より大きな共有プールが必要となります。SHARED_POOL_SIZE 初期化パラメータを使用して、共有プールのサイズをバイト単位で指定できます。
次のクエリを使用すると、共有プール内の空きメモリ量をモニタできます。
最大オープン カーソル数 - Oracle サーバのすべてのリソースが 1 つの接続によって消費されないようにするには、OPEN_CURSORS 初期化パラメータを使用して接続ごとのオープン カーソルの最大数を制限します。残念ながら、このパラメータのデフォルト値は WebLogic Server のようなシステムには小さすぎます。カーソル情報は、次のクエリを使用してモニタできます。 データベース ブロック サイズ - ブロックは、Oracle におけるデータ格納の基本単位で、I/O の最小単位でもあります。1 つのデータ ブロックは、ディスク上の物理データベースの特定のバイト数に相当します。このブロックという概念は Oracle RDBMS に固有のものですので、使用しているオペレーティング システムのブロック サイズと混同しないようにしてください。ブロック サイズは物理的なストレージに影響するため、この値を設定できるのはデータベースの作成時に限られ、データベース作成後は変更できません。このパラメータの現在の設定値は、次のクエリを使用して取得できます。 ソート領域のサイズ - ソート領域を大きくすると、クエリの処理中にメモリ内でソートを実行できるため、大規模なソートのパフォーマンスが向上します。ソート領域は接続ごとに 1 つしか確保できないため、このサイズの設定は重要になります。通常、この init.ora パラメータのデフォルト値は 6 ～ 8 データ ブロックです。この値は通常の OLTP 処理には十分ですが、意思決定支援処理、大規模なバルク処理、大規模なインデックス関連の処理などを行う場合は、より大きな値を設定しておく必要があります。この種の処理を実行する場合は、init.ora パラメータを次のようにチューニングします (デフォルトの設定値は 8K データ ブロック)。
Microsoft SQL Server
以下に、Microsoft SQL Server データベースのパフォーマンス チューニング パラメータに関するガイドラインを示します。これらのパラメータの詳細については、Microsoft SQL Server のマニュアルを参照してください。
高速 I/O デバイスには tempdb を格納する。 perfmon が I/O の増加を示す場合は回復間隔を広くする。 2KB 以上の I/O ブロック サイズを使用する。
Sybase
以下に、Sybase データベースのパフォーマンス チューニング パラメータに関するガイドラインを示します。これらのパラメータの詳細については、Sybase のマニュアルを参照してください。
回復間隔を狭めると、チェックポイント処理がより頻繁に発生するため I/O 処理が増加する。 2KB 以上の I/O ブロック サイズを使用する。 Sybase では SMP (symmetric multiprocessor) 環境でエンジンの数を制御するが、この設定の推奨値は CPU 数から 1 を引いた値とされている。
