Tweet

本連載はDB2 UDB V8のシステム管理者、およびアプリケーション開発者のために、パフォーマンス・チューニングに必要な技法を紹介する。記事の原文はIBM developerWorksで2004年4月に公開された「Best practices for tuning DB2 UDB v8.1 and its databases」で、DB2の設計、配置、構成、SQL、運用管理、モニタリングといった内容を、実践的な操作を中心に解説している。想定する読者はDB2データベース管理の中級レベルのスキルを持っているユーザーである。スクリーン・ショットなど一部のコンテンツは、日本語版のものに差し替えている。（編集局）

■各種使用率とボトルネック

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　ここでは、一般的にはDB2チューニングの範囲外であるが、データベース・パフォーマンスを大幅に低下させる可能性のある潜在的な問題について説明します。

CPU使用率

　総CPU使用率（ユーザー＋システム）が80％を超える場合、システムはCPU制約（「制約」は原文でbound、限界にあること）であると考えられます。一般的には、CPU使用率を（ほとんどの場合において）80％以下に抑えるようにします。これは、突発的な処理の増加に対応できるようにしておくためです。システムがCPU制約であると思われる場合、一概に何が原因であるとはいえません。効率の悪いアクセス・プランから、より多くのCPUを必要とする大量の同時接続まで、あらゆる原因が考えられるからです。

　UNIXでは、vmstatを使用してCPU使用率をモニタします（例えば「vmstat 3」）。Windowsでは、Perfmon.exeまたはタスク・マネージャを使用してモニタします。突発的な短時間の（1〜3秒程度の）100％ビジーは無視して、長期間の平均CPU使用率に注目します。

　リスト1はRed Hat Linux 8.0での出力例を示しており、重要な列は赤字で示してあります。この中で参照したいのは、ユーザーCPU使用率（us）とシステムCPU使用率（sy）の列です。id列はアイドル時間を表します。先頭の行は常に無視してください。ここで示されているシステムの場合、ユーザーCPU使用率が極めて高く、やがて通常の状態に戻っています。

• リスト1　vmstatの出力例（別ウィンドウで開きます）

　CPU使用率が高い原因としては、大きな表に対する表スキャンや索引スキャンが考えられます。（SQLスナップショットの中の）「rows read」の値が特に高いSQLステートメントを分析して、適切な索引を作成してみてください。

　また、プロセス・レベルでモニタすることにより、何がCPUを浪費しているのかを調べることができます。UNIXではpsを使用して（例えば「ps uax」）、WindowsではPerfmon.exeまたはタスク・マネージャを使用して、それぞれモニタします。突発的な短時間の（1〜3秒程度の）100％ビジーは無視して、長期間の平均値に注目します。

　例えばRed Hat Linux 8.0では、「ps uax」を実行することで、各プロセスがCPUをどれくらい使用しているかを参照できます。

• リスト2　psの出力例（別ウィンドウで開きます）

ディスク使用率

　ディスクが45％以上ビジーである場合（通常、%util列を参照します）、システムは入出力制約であると考えられます。ディスクがボトルネックになっている場合は、表スペースのコンテナが、使用可能なすべてのディスクにまたがっていることを確認してください。それでもディスク使用率が高い場合は、ディスクを増やす必要があります。

　UNIXではiostatを使用して（例えば「iostat 3」）、WindowsではPerfmon.exeを使用して、それぞれモニタします。iostatの出力書式は、残念ながら、使用するOSによって異なります。突発的な短時間の（1〜3秒程度の）100％ビジーは無視して、長期間の平均値に注目します。

　Linuxを使用している場合は、「iostat -d -x 3」コマンドを使用し、拡張ディスク情報を使用可能にして、サービス時間（svctm）が50ミリ秒以上のディスクと45％以上ビジーなディスクを探します。以下の出力例では、書式上の理由からいくつかの列を省略してあります。

• リスト3　iostatの出力例（別ウィンドウで開きます）

メモリとページング・スペースの使用率

　DB2の観点からすると、ページングが発生している場合、システムはメモリ制約であると考えられます。通常、ページングが発生するとパフォーマンスは大幅に低下します。

　UNIXでは、「lsps -a」を使用してページング・スペースの特性を表示し、vmstatを使用してモニタします（例えば「vmstat 3」）。Windowsでは、Perfmon.exeまたはタスク・マネージャを使用します。

　例えばRed Hat Linux 8.0では、スワップ情報に注目します。具体的には、ディスクからスワップインされたメモリの量とディスクにスワップアウトされたメモリの量が、スワップイン（si）とスワップアウト（so）の各列に、Kbytes/秒単位で（AIXでは4Kbytesページ/秒単位で）表示されます。

• リスト4　vmstatの出力例（別ウィンドウで開きます）

ネットワーク使用率

　通常、ネットワークは大きなボトルネックにはなりませんが、チューニングすることでパフォーマンスが向上する場合があります。ネットワークを介してDB2サーバと通信するときにパフォーマンスの問題が生じ、CPU使用率と入出力使用率がいずれも極めて低い場合は、システムがネットワーク制約であると考えられます。最もパフォーマンスが低下するのは、パーティション・データベースで、パーティション・ストラテジの結果がコロケーテッド結合にならない場合です。

　UNIXではnetpmonを使用して（例えば「netpmon -O all -o netpmon.out」）、WindowsではPerfmon.exeを使用して、それぞれモニタすることができます。

■情報源

• 日本IBMのDB2 Webサイトでは、DB2に関するあらゆる情報が得られます。
• DB2 Product Technical Library（英語サイト）では、DB2に関するさまざまな記事、資料、FAQなどのドキュメントが参照できます。
• DB2 White Papers（英語サイト）では、DB2に関するさまざまな技術資料が参照できます。
• IBM PartnerWorld for Developersでは、DB2開発者のためのリソース、フォーラム、資料などが利用できます。
• 「Diagnosing and Resolving Lock Problems with DB2 Universal Database」（developerWorks、2003年10月、英語サイト）では、DB2でロック・ストラテジがどのように実装されているか、およびそれに関連する問題の解決方法について論じられています。（連載完）

◇

編集局：本連載は今回で終了です。ご愛読ありがとうございました。

DB2チューニング・ベストプラクティス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード