Comments
Transcript
第 9 回 DB2 の診断と OS の診断の組み合わせ DB2 問題判別 習熟シリーズ
DB2 問題判別
習熟シリーズ
第 9 回 DB2 の診断と OS の診断の組み合わせ
第9回 DB2の診断とOSの診断の組み合わせ - インデックス
・セクション1:概要
・セクション2:アプリケーションの構築
・セクション3:診断ログとイベント・ログション
・セクション4:UNIXのオペレーティング・システム・エラーの例
・セクション5:パフォーマンスの問題の定義、初期のデータ収集
・セクション6:パフォーマンスの問題の例
・セクション7:まとめ
セクション1:概要
この回では、DB2が関係しているシステム・エラーやパフォーマンスの問題を定義および診断するための最初のス
テップを紹介します。具体的には、以下のことについて学びます。
●
●
●
●
DB2のツールやログから収集する情報
オペレーティング・システムのツールやログから収集する情報
収集する環境の情報
これらすべての情報をまとめて問題の調査に利用する方法
また、構成の理解、パフォーマンスとリソースのモニター、診断ログの基本的な分析などのトピックを取り上げま
す。
対象となるのは以下のプラットフォームです。
●
●
●
●
●
AIX
Solaris
HP-UX
Linux
Windows
対象読者と前提事項
以下の条件のうち少なくとも1つが当てはまるDB2の問題を報告または分析する、すべてのユーザーを対象としていま
す。
●
●
オペレーティング・システムまたはユーザーの環境が要因となっている可能性がある
CPU、メモリー、IPC (プロセス間通信)リソース、ディスクなど、オペレーティング・システムによって管理さ
れているリソースに問題がある
この回では、読者に以下のスキルが備わっていることを前提とします。
●
●
●
RAM、CPU、仮想メモリー、IPCリソース、入出力などのオペレーティング・システムの基本概念に通じている
オペレーティング・システムの基本的なコマンドに通じている
バッファー・プール、表スペース、ソート、並列性、アイドル・エージェント・プール、DB2プロセスの名前な
どを含むDB2の概念を理解している
この回の前に、『DB2 v7.2 Administration Guide』の以下の章を見直すことをお勧めします。
第4章 「Parallel Database Systems」（並列データベース・システム）
第20章 「Elements of Performance」（パフォーマンスの要素）
「Architecture and Processes Overview」（アーキテクチャーおよびプロセスのオー
第21章
バービュー）
第27章 「Operational Performance」（稼動パフォーマンス）
第32章 「Configuring DB2」（DB2の構成）
付録M
「Using the Windows NT(R)Performance Monitor」（Windows NT(R)のパフォーマン
ス・モニターを使う）
『Administration Guide』は、DB2 Technical Support Webサイトでオンラインで読むことができます。
開始前のセットアップ
利用可能な各プラットフォームにDB2 Enterprise Edition, version 7.2 FixPak以上をインストールする必要がありま
す。AIX、Linux、Solaris、Windowsの各プラットフォームに特有の動作やツールを取り上げている例もありま
す。UNIXの例の中には、サポートされているどのUNIXプラットフォームでも実行できるものもあります。ただし、
その場合も、具体的なコマンドやその出力は異なります。
db2samplコマンドを使ってSAMPLEデータベースを作成する必要があります。
作業に使用するシステムのアドミニストレーター権限が必要です。アドミニストレーター権限を獲得できない場合
は、いくつかの実習を完了できない可能性があります。
注:この回の例の中には、システムにストレスを与えるものがあります。このため、他のユーザーに影響が及ぶ可能性
があります。また、システムが不安定になる可能性もあります。
表記規則
ツールやユーティリティーの名前は、初出時には太字で表記されます。
すべてのコマンドおよびその出力は、モノスペース・フォントで表記されます。
例で使われているコマンド・オプションは、今後変更される可能性があります。ただし、その変更は必ずDB2 UDBの
マニュアルに記載されます。
著者について
Michael Cornishは、DB2 UDBサポート・チームのシニア・テクニカル・アナリストです。メモリー関連の問題、シス
テム・パフォーマンス、およびDB2とオペレーティング・システムの境界にまたがる問題の解決を専門としていま
す。
Michael Cornishの連絡先については、http://www.ibm.com/contact/employees/usのIBM Global Directoryをご覧ください。
電子メール・アドレスを調べることができます。
セクション2:アプリケーションの構築
システム構成とユーザー環境の情報の概要
メモリー、スワップ・ファイル、CPU、ディスク装置、およびその他のリソースに関連する問題は、オペレーティン
グ・システムがそれらのリソースをどのように管理しているのかを完全に理解していないと診断できない場合があり
ます。少なくとも、そのリソースがどのくらいあるのかや、ユーザーごとの制限がどうなっているのかがわからない
と、リソース関連の問題を定義することはできません(通常は、DB2インスタンス所有者のユーザーIDに対する制限が
対象になります)。
以下は、取得する必要がある重要な構成情報の例です。
●
●
●
●
●
●
●
●
●
オペレーティング・システムのパッチ・レベル、インストールされているソフトウェア、アップグレードの履
歴
CPUの数
RAMの量
スワップとファイル・キャッシュの設定
ユーザー・データとファイル・リソースの制限およびユーザーごとのプロセスの制限
IPCリソースの制限(メッセージ・キュー、共用メモリー・セグメント、セマフォー)
ディスク装置の種類(EMC、Shark、Network Access Storageソリューションなど)
マシンがその他の用途に使用されているかどうか(DB2がリソースを取り合うかどうか)
認証が行われる場所
ほとんどのプラットフォームには、リソースの情報を取得するための簡単なコマンドがあります。DB2 version 7.2,
FixPak 4の時点では、db2supportユーティリティーを使って、これらの情報やその他多くの情報を収集できます。実
際、db2supportの詳細システム出力(detailed_system_output.htmlファイル)には、この回で使用されている多くのコマン
ドの構文が含まれています。
この回の最初の実習では、このdb2supportユーティリティーを実行する方法を説明します。その後の実習では、トラッ
プ・ファイルを取り上げます。トラップ・ファイルには、DB2によって生成されるさらに多くのデータが含まれてい
ます。これらのデータは、ユーザー環境やリソースの制限を把握するのに役立ちます。
実習: db2supportコマンドの実行
1. 利用可能な各プラットフォームで、db2startコマンドを使ってDB2を開始します。
2. db2supportからの出力を格納するためのディレクトリーを作成します(既にSAMPLEデータベースがあるものと仮
定しています)。
3. そのディレクトリーに移動して、次のコマンドを実行します。
db2support <directory> -d SAMPLE
4. コンソール出力を確認します。特に、収集されている情報の種類に注目します。 この出力は、次のようになっ
ているはずです。
Collecting "System files"
"SQLDBCON"
"db2rhist.asc"
"SQLOGCTL.LFH"
"SQLBP.1"
"SQLBP.2"
"SQLSPCS.1"
"SQLSPCS.2"
"db2systm"
"db2cli.ini"
"sqldbdir"
"sqldbbak"
"sqldbins"
"sqlnodir"
"sqlnobak"
"archive.log"
Collecting "Basic operating system and hardware information"
Collecting "System resource info (disk, CPU, memory)"
Collecting "Operating system and level"
Collecting "JDK Level"
Collecting "DB2 Release Info"
Etc.
5. 次に、Webブラウザーを使ってdetailed_system_output.htmlファイルを表示します。 お使いの各システムで、以下
の情報を確認してください。
❍
❍
❍
❍
❍
CPUの数
RAMの量
オペレーティング・システムのレベル
ユーザー環境
ユーザー・リソースの制限(UNIX ulimitコマンド)
実習: DB2トラップ・ファイルの環境情報の確認
1. UNIXシステムで、DB2が開始されていることを確認し、次のコマンドを実行します。
db2_call_stack
このコマンドは、t<pid>.<node>という形式の、「トラップ」ファイルと呼ばれるファイルをDB2診断ディレクト
リーに生成します(<pid>は情報が属するDB2プロセスのID、<node>はデータベース・パーティションの番
号)。Extended - Enterprise Edition製品を実行しているシステム以外は、ノードは000になります。
2. いずれかのトラップ・ファイルで、以下の情報を見つけます。
❍
❍
❍
DB2のコード・レベル
Data seg top (要求された専用アドレス・スペースの最大サイズ)
Cur data size (専用アドレス・スペースの上限)
❍
❍
❍
❍
Cur core size (コア・ファイル・サイズの上限)
Signal Handlers
Environment variables
map output (ロードされたライブラリー)
例: トラップ・ファイル(抜粋):
2002-11-08-00.12.37.810012 : DB2 v7.1.0.60 s020313 SQL07024
S:AIX R:3 V:4 M:0009028F4C00 N:panipuri
mcornish.000 : db2agent (TEST) (0x1)
Signal #36
Data seg top [sbrk(0)] = 0x209C4020
Cur data size (bytes) = 0xF424000
Cur stack size (bytes) = 0x10000000
Cur core size (bytes) = 0x7FFFFFFF
...
Signal Handlers
SIGABRT
: f1b09688
SIGBUS
: default
SIGCHLD
: f1b109b4
SIGDANGER
: f1b09694
SIGEMT
: default
SIGGRANT
: f1b096ac
SIGILL
: default
SIGINT
: f1b096b8
...
Environment variables
DB2INSTPATH=/home/mcornish/mcornish
HOME=/home/mcornish
PWD=/home/mcornish/sqllib/db2dump
TZ=EST5EDT
DB2COMM=TCPIP
DB2INSTANCE=mcornish
関連するDB2構成情報
以下は、DB2の構成について収集する必要がある最も一般的な項目です。
●
●
●
●
●
データベース・マネージャー構成(db2 get dbm cfg)
データベース構成(db2 get db cfg for <database >)
DB2レジストリー(db2set -all)
ノード構成(db2nodes.cfg)
バッファー・プールとノードの定義(SYSCAT.BUFFERPOOLS表、SYSCAT.BUFFERPOOLNODES
表、SYSCAT.NODEGROUPDEF表)
これらの項目には、使用される「可能性がある」リソースを量る目安となる、重要なDB2構成パラメーターがいくつ
か含まれています。
各アクティブ・データベースの共用メモリー:
●
●
●
●
●
約1.1 * (バッファー・プール、dbheap、パッケージ・キャッシュ、ユーティリティー・ヒープ、locklist、およ
びsheapthres (intra_parallelが使用可能になっている場合))
拡張記憶域(ESTORE) - ESTOREセグメントのメモリー + 各ESTOREページごとに100バイト (ESTOREページの
数 = ESTOREメモリーの合計/ESTOREが使用可能になっているバッファー・プールの最大ページ・サイズ)
WindowsのAWE (Address Windowing Extensions) (バッファー・プールがAWEを使用するように構成されている場
合)。db2set -allの出力にDB2_AWEがリストされている場合は、バッファー・プールでAWEが使用されていま
す。
APP_CTL_HEAP_SZ (DB2 EEEおよびSMPデータベースでアプリケーションごとに1つ)
DB2_FORCE_FCM_BP (このレジストリー設定が設定されている場合、すべてのデータベース・パーティション
に対して1つの共用メモリー・セグメントが使用されます)
エージェントの専用メモリー:
●
●
●
WindowsのAGENT_STACK_SZ
DB2MEMDISCLAIM、DB2MEMMAXFREE (エージェントごとに保持される空きメモリーの最大サイズ) - DB2
レジストリー変数
照会ヒープ・サイズ、ソート・ヒープ、ステートメント・ヒープ、アプリケーション・ヒープ(これらの最大サ
イズは、同時に割り当てられているとは限りません。また、エージェントごとに複数のソート・ヒープが同時
に割り当てられていることもあります)。
DB2プロセスの数:
●
●
MAXAGENTS、NUM_POOLAGENTS
各データベースのプリフェッチャー(IOSERVERS)、ページ・クリーナー(IOCLEANERS)
並行して実行されているDB2プロセスの数:
●
●
●
インスタンス、データベース・パーティション、データベースの数
MAXAGENTS、MAXCAGENTS、INTRA_PARALLEL、MAX_QUERYDEGREE、MAXAPPLS、DFT_DEGREE
データベース構成のMAXAPPLS、DFT_DEGREE
各プラットフォームでの構成情報の取得
次の表には、構成情報を取得するための便利なコマンドが含まれています。
AIX
HP-UX
Solaris
Linux
OS level
/usr/sbin/oslevel
/usr/bin/uname a
/usr/bin/uname -a
/bin/uname a
Software
/usr/bin/lslpp -ah
/usr/sbin/swlist v
/usr/bin/showrev p
/bin/rpm qa
CPUs
/usr/sbin/lsdev -C (grep
proc)
/usr/sbin/ioscan
(grep processor)
/usr/sbin/psrinfo v
/bin/dmesg
(grep CPU)
Memory
/usr/sbin/lsattr -El sys0
/usr/sbin/dmesg
(grep realmem)
(grep Physical)
/usr/samples/kernel/vmtune
/usr/sbin/prtconf
(grep Memory)
/bin/dmesg
(grep
Memory)
/usr/bin/free
IPC
resources
N/A
/usr/sbin/sysdef -i
/etc/system (file)
/usr/bin/ipcs
-l
ulimit -a
ulimit -a
ulimit -a
set
set
set
/usr/sbin/kmtune
SAM GUI tool
User limits
ulimit -a
/etc/security/limits (file)
User
set
environment
Windows NTには、システム情報を取得するための便利なインターフェースが用意されています。
winmsd /af
このコマンドを実行すると、<machine_name>.TXTというファイルが現在のディレクトリーに作成されます。
Windows 2000(R)およびXP(R)では、次のコマンドを使用します。
<OSdrv>:¥Program Files¥Common Files¥Microsoft
Shared¥MsInfo¥Msinfo32 /report <file>:
このコマンドでは、インストールされているソフトウェアは報告されません。この情報を取得する方法として
は、regeditツールを使って、レジストリー(少なくともHKEY_LOCAL_MACHINE¥SOFTWAREブランチ)をファイルに
エクスポートする方法があります。
セクション3: 診断ログとイベント・ログ
DB2とシステムのイベントやエラーの関連付け
システム・メッセージやエラー・ログは、無視されることが多すぎます。問題判別や問題調査の初期段階で簡単な作
業を1つ行うだけで、問題解決に要する時間を数時間、数日、場合によっては数週間も節約できます。その作業とは、
異なるログのエントリーを比較して、時間および対象となるリソースの両方について関係がありそうなエントリーを
書き留めることです。
常に問題判別に関連するとは限りませんが、多くの場合、最大の手がかりはシステム・ログから簡単に得ることがで
きます。報告されているシステムの問題をDB2のエラーと関連付けることができれば、たいていは、DB2の症状を引
き起こしている直接の原因を特定できます。ディスク・エラー、ネットワーク・エラー、ハードウェア・エラーなど
は、その明らかな例です。それほど明らかでない例としては、たとえばドメイン・コントローラーやNISサーバーな
ど、別のマシンで報告されている問題があります。こうした問題は、接続時間や認証に影響を与える可能性がありま
す。
システム・ログを調べると、安定性を評価することができます。新しいシステムで問題が報告された場合などには特
に有効です。一般的なアプリケーションで断続的にトラップが発生する場合には、基になるハードウェアに問題があ
る可能性があります。
このほか、システム・ログからは次のような情報も得られます。
●
●
●
システムがリブートしたときなどの重要なイベント
システム上のDB2トラップ(および失敗している他のソフトウェアのエラー/トラップ/例外)の履歴
カーネル・パニック、ファイル・システム・スペースの不足、スワップ・スペースの不足などのエラー(これら
のエラーが発生すると、システムで新しいプロセスを作成したりフォークしたりできなくなる場合があります)
システム・ログは、db2diag.logのクラッシュ・エントリーを問題の原因として除外するのに役立つ場合もあります。
一貫性のあるDB2クラッシュ・リカバリーについて調査をしていたときに、システムがリブートしていたことがわ
かって解決したことがあります。なんと、清掃係が毎朝同じ時間にコンピューターのプラグを抜いていたことが原因
だったのです。
たとえば、先行するエラーがないクラッシュ・リカバリーのエントリーがdb2diag.logにあったとします。
2002-11-11-02.52.09.031000
Instance:DB2
Node:000
PID:139(db2syscs.exe)
TID:230
Appid:*LOCAL.DB2.021111075207
base_sys_utilities sqledint
Probe:0
Database:SAMPLE
Crash Recovery is needed.
そしてその直前に、Windowsのシステム・ログに次のようなエントリーが記録されていたとします。
11/11/02
2:49:26 AM EventLog
Information None
6005
N/A SERVER1 The Event log service was started.
11/11/02
2:49:26 AM EventLog
Information None
6009
N/A SERVER1 Microsoft (R) Windows NT (R) 4.0 1381 Service Pack 4
Multiprocessor Free.
この場合、このDB2のクラッシュ・リカバリーは、Windowsがシャットダウンした結果であると考えられます。
この情報の関連付けの原理は、あらゆるソースのログや、ユーザーが確認できる症状に拡張できます。たとえば、別
のアプリケーションのログから関連するエントリーを見つけて記録しておくと、たとえそれらを完全には解釈できな
かったとしても、非常に役に立つことがあります。
UNIX(R)のシステム・エラー・ログとメッセージ・ログ
次の表は、各UNIXプラットフォームのログの場所を示しています。
AIX
HP-UX
Linux
Solaris
Error /
/usr/bin/errpt - /var/adm/syslog/syslog.log /var/log/messages* /var/adm/messages*
a
/usr/sbin/dmesg
Message
Logs
実習: システムのログの調査
1.
2.
3.
4.
5.
6.
上の表を使ってシステム・ログを見つけます。
db2やsqlなどのキーワードを検索します。
システムが最後にリブートしたのがいつかわかりますか?
ログはどのような順序で並んでいますか?
タイム・スタンプを探します。特殊文字のために見つけにくいことがあります。
DB2のトラップは報告されていますか?報告されていない場合は、以下の手順を実行します。
●
●
●
●
●
●
db2stop (必要に応じてアプリケーションを強制的に切断します)
db2start
db2 connect to sample
現在の接続で使用しているdb2agentのプロセスIDを確認します。
/usr/bin/ps -elf ￨ grep $DB2INSTANCE ￨ grep db2a
db2agentにシグナルを送ります。
/ kill -11 <db2agent_pid>
db2 list tables
kill -11 <db2agent_pid>
システム・ログを調べます。このトラップの呼び出しスタックはありますか?
Windows(R)イベント・ログとワトソン博士のログ
Windowsイベント・ログ:
Windowsのイベント・ログからも有益な情報を得ることができます。DB2のクラッシュや、システム・リソースに関
連するその他の不可解なエラーの場合、通常システム・イベント・ログが最も有効ですが、3つの種類すべてのイベン
ト・ログを取得しておく価値があります。
●
●
●
システム
アプリケーション
セキュリティー
Windows 2000でイベント・ログにアクセスするには
1. [コントロール パネル]の[管理ツール]を選択します。
2. [イベント ビューア]を選択します。
Windows NTでイベント・ログにアクセスするには
1. [スタート メニュー] -> [プログラム] -> [管理ツール] -> [イベント ビューア] を選択します。
イベント・ログのエクスポート:
イベント・ビューアでは、イベント・ログを2つの形式でエクスポートできます。1つは.evt形式で、この形式でエクス
ポートした場合、イベント・ビューアに再度ロードすることができます(別のマシンのイベント・ビューアにロードす
るなど)。もう1つはテキスト形式です。
●
●
NTでは、[ログ]メニューの[上書き保存]を選択します。
Windows 2000では、[操作]メニューの[ログ ファイルの名前を付けて保存]を選択します。
イベント・ビューア形式では、GUIを使って並び順を切り替えたり、特定のイベントにフィルターをかけたり、前後
に移動したりできるので、作業がしやすくなります。
テキスト・ファイルには大きな利点が1つあります。それは、タイム・スタンプを信頼できるということです。イベン
ト・ログを.evt形式でエクスポートすると、タイム・スタンプは協定世界時でエクスポートされ、ビューアでマシンの
ローカル時間に変換されます。注意しないと、タイムゾーンの違いのために重要なイベントを見逃してしまう可能性
があります。
このほか、テキスト・ファイルには、検索しやすいという利点もあります。ただし、イベント・ログも、いったん別
のマシンからイベント・ビューアにロードしてしまえば、簡単にテキスト形式で再度エクスポートできます。
ワトソン博士のログ
ワトソン博士のログ(drwtsn32.log)は、システム上で発生したすべての例外の履歴です。ワトソン博士のログよりDB2
のトラップ・ファイルの方が便利ですが、システム全体の安定性を評価したり、DB2トラップの履歴のドキュメント
として利用したりする際には役に立ちます。デフォルトのパスは、<install_drive>:¥Documents and Settings¥All
Users¥Documents¥DrWatsonです。
オペレーティング・システム・エラーの特定と調査
システム・リソースの問題は、db2diag.logの明確なエラーによって示される場合もあれば、シグナルや例外によって
知らされる場合もあります。db2diag.logにダンプされる低い値の多くは、オペレーティング・システムのエラーで
す。
ほとんどのUNIXシステムでは、/usr/include/sys/errno.h.でシステム・エラーを確認できます。以下は最も一般的なシス
テム・エラーです。
#define
#define
#define
#define
#define
#define
#define
#define
EPERM
ENOENT
EIO
ENOMEM
EACCES
ETXTBSY
EFBIG
ENOSPC
1
2
5
12
13
26
27
28
/*
/*
/*
/*
/*
/*
/*
/*
Not super-user
No such file or directory
I/O error
Not enough core
Permission denied
Text file busy
File too large
No space left on device
*/
*/
*/
*/
*/
*/
*/
*/
Windowsでは、コンパイラーやWindows SDKと一緒に、システム・エラー・ヘッダー・ファイルがシステムにインス
トールされます。以下は、定数の例です。
#define ERROR_FILE_NOT_FOUND
#define ERROR_ACCESS_DENIED
#define ERROR_INVALID_ACCESS
2L
5L
12L
Windowsでは、net helpmsgコマンドを呼び出すこともできます。このコマンドから、エラーに関する情報が得られる
場合もあります。以下に例を示します。
net helpmsg 1450
Insufficient system resources exist to complete
the requested service.
UNIXとWindowsの両方のプラットフォームについて、利用できる問題データベースを検索する以外に、Web上のリ
ソースを使ってエラーを調査することもできます。エラー定数(ENOSPC(28ではなく)など)や、呼び出されているオペ
レーティング・システムのAPI(それがわかる場合)を以下の場所で検索すると、多くの場合、エラーの原因の候補がい
くつか見つかります。
●
●
●
●
●
●
AIX: publib.boulder.ibm.com/cgi-bin/ds_form?lang=en_US
HP-UX: docs.hp.com/
Solaris: docs.sun.com/
Linux: fokus.gmd.de/linux/
Windows: support.microsoft.com/
このほか、DB2のオンライン・サポート・サイトももちろんご利用いただけます
セクション4:UNIXのオペレーティング・システム・エラーの例
ファイル・サイズの上限への到達
バックアップを実行する際には、ユーザー・ファイル・サイズの上限か、2GBというファイル・システムのファイル
の上限に達してしまうことがよくあります。ここでは、あらかじめ割り当てられたDB2 DMSファイル・コンテナーの
上限に達する例について見てみます(通常は起こるはずのないことです)。これは「強制的に作った」例ですが、ユー
ザー制限が変更されたり、インスタンスID以外のID (rootなど)によってDB2が開始されたりすることは、ときどきあり
ます。DB2を開始するユーザーIDと、そのユーザーに関連付けられている制限を確認することは重要です。
1. SAMPLEデータベースで、サイズが1000 4KページのDMS表スペースを作成します。
db2 create tablespace DMS managed by database using (FILE 'dms' 1000)
2. 作成した表スペースにemployee表を追加します。
db2 create table emp like employee in DMS
db2 insert into emp select ¥* from employee
db2 insert into emp select ¥* from emp (あと9回繰り返します)
3. インスタンスをkillします。
db2_kill (重要なデータベースでは行わないでください)
4. ユーザー・ファイル・サイズの上限をDMSコンテナーのサイズより低くします。
ulimit -f 1000 (単位は1Kです)
5. インスタンスを再開始し、データベースに接続してみます。
db2start
db2 connect to sample
次のエラー・メッセージが返されるはずです。
SQL1042C An unexpected system error occurred. SQLSTATE=58004
db2diag.logには、次のようなエントリーが含まれています。
2002-11-11-00.32.24.930242
Instance:mcornish Node:000
PID:8226(db2pclnr)
Appid:none
oper_system_services sqloAioReturn ( sqlommapwrite on AIX ) Probe:36
errno: 0000 001b
....
...
2002-11-11-00.32.26.249910
Instance:mcornish Node:000
PID:8220(db2agent (SAMPLE))
Appid:*LOCAL.mcornish.021111053213
buffer_pool_services sqlbWritePageToContainer Probe:20 Database:SAMPLE
SMS Tablespace 3(DMS) is FULL or file is too large (at OS or user limit).
Detected on Container 0. ContPage= 290 Obj=4 Type=0
ここでの主な手がかりは(db2diag.log自体に含まれているメッセージ以外では)、エラー・コード0x1b = 27です。このエ
ラー・コードを/usr/sys/include/errno.hで調べてみます。
#define EFBIG
27
/* File too large
*/
AIXのドキュメント・サイトで検索すると、ヒットする上位のページの中に以下のページがあります。これは、write()
のマニュアル・ページです。
EFBIG
(AIX versions 4.2 and later) An attempt was
made to write a file that exceeds the process' file size
limit or the maximum file size.
プロセスごとのIPC制限
ここでは、32ビットDB2/AIXでIPCの制限に達する例を紹介します。同じシナリオは、他のUNIXオペレーティング・
システムでも観察できますが、データベース接続/別名の数を増やさなければならない場合もあります。他のUNIXオ
ペレーティング・システムでは、カーネル・パラメーターshmsys:shmsegが、1つのプロセスからの接続の最大数を制
御しています。この値をチェックするには、sysdefコマンドを使用します。
1. サンプル・データベースを異なる11の別名としてカタログします。
db2 catalog db sample as sample1
db2 catalog db sample as sample2
Etc.
2. タイプ2の接続を使用するようにCLP (Command-Line Process)を設定します。これにより、同じアプリケーショ
ンで複数のデータベースに接続できるようになります。
db2 terminate
db2 set client connect 2
3. 11のデータベース別名のそれぞれに接続してみます。
db2 connect to sample1
db2 connect to sample2
Etc.
11番目のデータベースに接続しようとしたところで、次のエラーが返されます。
SQL1224N A database agent could not be started to service a request, or
was terminated as a result of a database system shutdown or a force command.
SQLSTATE=55032
db2diag.logには、共用メモリーへの接続に関するオペレーティング・システム・エラーが含まれています。
2002-11-13-08.43.57.382554
Instance:mcornish Node:000
PID:189336(db2bp) Appid:*LOCAL.mcornish.021113134353
oper_system_services sqlocshr2
Probe:200
0000 0018
0x18を10進数に変換すると24になります。/usr/include/sys/errno.hで調べてみると、次のような説明があります。
#define EMFILE 24
/* Too many open files
*/
この問題の原因と解決法は、問題データベースやオンライン・サポート・サイトを検索することによっておそらく見
つけられます。また、UNIX上の共用メモリーへの接続はshmat()関数によって行われるということを知っている場合
は、shmat()のマニュアル・ページを調べて以下の情報を見つけることができます。
EMFILE The number of shared memory segments attached to
the calling process exceeds the system-imposed limit.
この問題には、さまざまな解決法があります。たとえば、AIXでEXTSHMを実装する、SolarisやHP-UX
でshmsys:shmsegを増やす、TCP/IPループバックでデータベースをカタログしてローカル接続の共用メモリー・セグメ
ントを使用しないようにする、などの方法があります。
システム全体のIPC制限
ハング、データベース・マネージャーやデータベースの開始の問題、ピーク時の負荷が増えた場合のエラーなどは、
不適切なIPCリソース構成が原因となっていることがよくあります。
システム上のIPCリソースの使用状況は、ipcs、awk、およびwcの各コマンドを組み合わせて使用すると、すばやく
チェックできます。下で言及されているパラメーターはAIXには当てはまりませんが(IPCリソースはAIXでは構成でき
ない)、それでもモニターは、システム上で割り当てられているIPCリソースが多すぎないかどうかを確認するのに役
立ちます。
例として、Linuxシステムでの接続で予期しないエラーが返された後に、ipcs -lコマンドを使ってさまざまなIPC制限
をチェックしました。
<-db2inst1->‾== > ipcs -l
------ Shared Memory Limits -------max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1
------ Semaphore Limits -------max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767
------ Messages: Limits -------max queues system wide = 1024
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384
次に、システム上のIPCリソースの使用状況をチェックしました(Linuxでは、ipcs -uで行うこともできます)。
●
●
●
●
共用メモリーID (shmmni)
ipcs -m ￨ wc -l
Output: 99 (subtract 4 for output head and tail = 95)
メッセージ・キューID (msgmni)
ipcs -q ￨ wc -l
Output: 96 (subtract 4 for output head and tail = 92)
セマフォー集合/配列(semmni)
ipcs -s ￨ wc -l
Output:132 (subtract 4 for output head and tail = 128)
システム上のセマフォー(semmns)
ipcs -s￨awk '{sems=sems+$5} END {print sems}'
Output: 166
128というセマフォー配列の最大数に達していたことがわかります。この場合は、オペレーティング・システムのマ
ニュアルで、semmniを増やす方法を調べます。
DB2がIPCリソースをどのように使用しているのかを把握するために、以下の各ステップの後でipcsコマンドを実行し
て、インスタンス所有者のIDをgrepしてみてください。なお、お使いのUNIXプラットフォームによっては、NSEMS
が別の列にある場合もあります。
Session
Session
Session
Session
Session
1:
1:
2:
2:
3:
db2start
db2 connect to sample
db2 create db test
db2 connect to test
db2 connect to test
セクション5:パフォーマンスの問題の定義、初期のデータ収集
問題の明確化
パフォーマンスの問題は、広範囲のシナリオに当てはまります。
●
●
●
●
●
●
●
照会の実行が識別可能なほど予想より遅い
ワークロードやバッチ・ジョブが予想ほど早く完了しない、トランザクション速度やスループットが低下して
いる
システム全体がスローダウンしている
CPU、入出力、メモリーなど、なんらかの種類のシステム・リソースがボトルネックになっている疑いがある
照会やワークロードが、予想より多くまたは利用できるより多くのリソースを消費している
あるシステムと別のシステムとの間で比較が行われている
照会、アプリケーション、DB2、またはシステムがハングする
上に示したシナリオには、やや微妙なところがあります。問題判別を目的とする場合は、予想と違うということと、
リソースのキャパシティーを越えているということとを明確に区別することが重要です。ときには、その両方に当て
はまる場合もあります。
問題判別を目的とする場合、ハングはパフォーマンスの問題とひとまとめにすることができます。これは、多くの調
査方法がこの両方に当てはまるためです。また、問題をハングかパフォーマンスの問題かに分けて定義することが初
めのうちは不可能な場合もあります。たとえば、実行時間の長いジョブは、応答を待っているユーザーにはハングし
たように見えることがあります。実際には、データベース・サーバー上でアプリケーションのためにたくさんのアク
ティビティーが行われていたとしても、それはユーザーにはわかりません。このほか、深刻なシステム・スローダウ
ンの間に大量のアクティビティーが蓄積されて、ほとんどすべてのコマンドがシステムでハングしているように見え
る場合もあります。
どこで症状が観察されたのか(照会/アプリケーション/システム・リソース)、何が問題なのか(遅い、使用されているリ
ソースが多すぎるなど)、という観点から問題の特性を正しく記述するだけではまだ十分とはいえません。このほかに
も、問題の背景を明らかにするためのさまざまな情報が必要になります。
●
●
●
●
●
●
●
問題が発生し始めたのはいつか、最近変更されたものがあるとしたらそれは何か(ハードウェアやソフトウェア
のアップグレード、新しいアプリケーションの導入、チューニング、ユーザーの追加など)
どのくらいの頻度で発生するか
厳密には何が誰によって観察されたのか
モニター、チューニング、およびその他の変更に関して、これまでにどのような処置を取ったか
要件は何か(できる限り詳しく)
どのようなベンチマークを取ったか
システムでその他の問題が発生している場合、それは何か
すばやく実行できるシステムの診断
以下は、UNIX上で利用できる一般的なモニター・ツールです。
AIX
HP-UX
Linux
Solaris
CPU
vmstat
vmstat
vmstat
vmstat
mpstat
I/O
iostat
iostat -xt
iostat -t
iostat -xcn
Memory
ps aug
ps -elf
vmstat
ipcs -a
lsps -a
/usr/samples/kernel/vmtune
ps -elf
vmstat
ipcs -a
swapinfo -t
ps -aelf
vmstat
ipcs -a
free
/usr/bin/ps -elf
/usr/ucb/ps avwx
vmstat
ipcs -a
利用できるツールはこのほかにもたくさんありますが、パフォーマンスの問題の調査では、ほとんどの場合、これら
のネイティブ・ツールがあれば十分です。なお、iostat、vmstat、mpstatの各ツールについては、通常、後ろに2つの引
数(間隔と繰り返しの回数)を指定する必要があります。以下に例を示します。
vmstat 1 10
このコマンドを実行すると、10のスナップショットが1秒の間隔をおいて表示されます。最初のレコードは、システム
が始動されてからの統計情報を表します。通常、このレコードは無視してかまいません。
以下は、モニター情報を収集する際の原則です。
1. 必ず十分な量の出力を、フィルターを適用せずにキャプチャーします。システム全体の様子を見ることが重要
です。システムの動作や、DB2が利用できるリソースの量に、実行されている他のソフトウェアが影響を与えて
いることもよくあります。
2. 必ず少なくとも2回分のデータをキャプチャーします。2回分のデータがないと、問題が発生したときにデータ
要素が増加しているかどうかがわからないため、いくつかの累積データは意味がなくなります。問題が発生し
ている間や、問題の発生に至るまでの間に、ある程度の期間にわたって測定することが非常に重要です。
3. モニター・データを収集している間にDB2トレースを実行するなど、じゃまになるような診断を行わないように
します。
4. 問題が発生しているときにデータを収集するようにします。驚くべきことに、問題とは関係ないデータの確認
に多くの時間が費やされています。
5. 出力ファイルにタイム・スタンプを埋め込むスクリプトを使ってデータを収集します。たとえば、uptimeコマン
ドを使用できます。これにより、データを関連付けたり、どの期間のデータなのかを把握したりしやすくなり
ます。以下に例を示します。
uptime > > vmstat.out ;
vmstat 1 10 > > vmstat.out
6. 継続的なモニターが必要な場合は、UNIXのsarコマンドや、Windowsのperfmonツールのロギング・オプションを
使用することを検討します。
Windowsでシステムに関する情報を収集するための最もすばやい方法は、[タスク マネージャ]のスクリーン・スナッ
プショットを取ることです。たとえば、以下は、[タスク マネージャ]の[プロセス]タブのスクリーン・スナップ
ショットです。それぞれの列には、CPU、メモリー、および入出力のプロセスごとの統計情報が表示されています([
表示]->[列の選択] をクリックすると、[タスク マネージャ]をカスタマイズできます)。下の出力は、メモリー使用量の
順に並んでいます。これにより、通常はdb2syscs.exe (データベース・インスタンスのプロセス)が一番上の方に表示さ
れます。
すばやく実行できるDB2の診断
DB2のスナップショット・モニターは、問題をすばやく絞り込むのに便利なツールです。デフォルトでモニターのス
イッチがオンになっていない場合は、現在のセッションに対してすべてオンにします。
db2 update monitor switches using BUFFERPOOL on LOCK on
SORT on STATEMENT on TABLE on UOW on SORT on
注: 一時表の作成率が高い大規模なシステムでは、表のスイッチをオンにするとパフォーマンスの低下を招くおそれが
あります。パフォーマンスが低下した場合は、表のスイッチをオフに戻してください。
このほか、DB2 EEE環境を対象としている場合は、以下のコマンドを実行して、問題が発生しているデータ・パー
ティションをモニターするようにします。
db2 terminate
export DB2NODE=<partition number>
db2 update monitor switches
db2 get snapshot ...
問題が既に特定のアプリケーションや照会に絞り込まれているのでない限り、データベース・マネージャー、データ
ベース、バッファー・プール、表スペースなど、より全体的なスナップショットを繰り返す(少なくとも2回、できれ
ば3回)ことから始めることをお勧めします。アプリケーション、表、動的SQLなどのスナップショットでは、出力が
はるかに大きくなります。問題を定義する段階では、データベースとデータベース・マネージャーの出力から始め
て、どのような種類のアクティビティーが行われているのかを把握するのが最善の方法になります(サーバーで実行さ
れているエージェントの数、存在している接続の数、ロックの問題が発生しているかどうか、バッファー・プール全
体のヒット率、入出力時間、ソート・アクティビティーなど)。
継続的なデータベース・モニターのためのスクリプトが必要になることもよくあります。以下は、そうしたスクリプ
トの例です。このスクリプトでは、iostatとvmstatのタイミングによってループの回数を制御しています。
while [ 1 ]
do
datestamp=`date +"%m%d"`.`date +"%H%M"`
db2 get snapshot for database manager > dbmsnap.$datestamp
db2 get snapshot for database on SAMPLE > dbsnap.$datestamp
... etc. for each desired type of snapshot.
ps -elf ￨ sort +5 -rn > pself.$datestamp
ps aux ￨ sort +5 -rn > psaux.$datestamp
ipcs -a > ipcs.$datestamp
uptime >> > vmstat.out
vmstat 1 11 > > vmstat.out
echo "" > > vmstat.out
uptime > iostat.$datestamp
iostat 30 16 >> iostat.$datestamp
done
DB2の関数呼び出しスタック、トラップ・ファイル、トレース
このほかに役に立つ可能性がある情報としては、DB2トレースとスタック・トレースバックがあります。これらはい
ずれも、実行されている関数を示します。たいていは、関数の名前だけから、プロセスで何が行われているのかがあ
る程度わかります。
ほとんどのDB2コマンドがハングしているのに、サーバーではまだ多くのアクティビティーが行われているという場
合は、DB2コマンドのDB2トレースを取得し(タイム・スタンプ・オプション-tを指定し、-iスイッチを使って最初の
トレース・レコードを保持)、30秒後に別のセッションからトレースをダンプします。
セッション1:
db2trc on -i 8000000 -t
db2 connect to sample
<30秒待機>
セッション2:
db2trc dmp trace.out
db2trc off
db2trc flw trace.out trace.flw
db2trc fmt trace.out trace.fmt
スタック・トレースバックは、UNIXではdb2_call_stackコマンドで取得できます。このコマンドは、判読可能なトラッ
プ・ファイルt<pid>.<node>をDIAGPATHに作成します。Windowsの場合は、次のコマンドを使用します。
db2bddbg -d db2ntDumpTid <any_path> -1 <any_file>
結果として作成されるバイナリー・ファイルは、db2xprtユーティリティーを使ってフォーマットできます。このツー
ルはDB2に同梱されていませんが、FixPakダウンロード・サイトの該当するディレクトリーから、正しいフォーマッ
トのために必要なシンボル・ファイルと一緒にダウンロードできます。使い方については、この後の例を参照してく
ださい。
応答していない1つのアプリケーションまたはエージェントがはっきりしている場合は、そのプロセスまたはプロセス
のグループ専用のトレースと呼び出しスタック診断を取得できます。db2トレースでは、-pオプションを使用すると、
特定のプロセスのトレースを取得できます。個々のプロセスのDB2診断トラップ・ファイルを生成する方法、および
特定のプロセスやスレッドのトレースを初期化する方法については、次の表を参照してください(プロセスがなかなか
ループから抜けられず、トレース・レコードの書き込みを開始するかどうかを指示する関数を通過できない場合もあ
ります)。
呼び出しスタックの生成
生成 トレースの初期化
AIX
kill -PRE <process id>
kill -GRANT <process id>
Other UNIX
kill -URG <process id>
kill -PROF <process id>
Windows
db2bddbg -d db2ntDumpTid <path> <thread>
<file>
Not Applicable
なお、Windows上の目的のスレッドは、アプリケーション・スナップショットやWindowsのパフォーマンス・モニ
ターから取得できます。Windowsのパフォーマンス・モニターでは、たとえば、CPUを過度に使用している特定のス
レッドを確認できます。
Windowsのスタック・ダンプ・ファイルのフォーマット
DB2を開始し、次のコマンドを使って、Windowsの「未加工の」スタック・ダンプ・ファイルを作成します。
db2bddbg -d db2ntDumpTid C:¥TEMP -l stack.dmp
次に、適切なdebug.zipファイルをダウンロードし、C:¥db2debugなどのディレクトリーにunzipします。DB2 Version
7.2, FixPak 7を実行している場合、ダウンロードするのは以下のファイルになります。
ftp.software.ibm.com/ps/products/db2/fixes/english-us/db2ntv7/FP7_WR21311/Debug.zip
次に、stack.dmpをフォーマットします(引数を何も指定せずにdb2xprtを実行すると、構文のヘルプが表示されます)。
C:¥db2debug¥db2xprt /p C:¥db2debug stack.dmp stack.fmt
どのレベルのDB2のバイナリー・スタック・ダンプ・ファイルも、この方法でフォーマットできます。別のレベルを
実行している別のマシンのスタック・ダンプ・ファイルをフォーマットすることさえ可能です。その場合は、デバッ
グ・ファイルを別のディレクトリーに置いて、/pパラメーターでそのディレクトリーを指定するだけです。
出力に"date mismatch"という警告が表示される場合があります。日付は同じだが時刻が厳密には一致しない(前後に数
秒ずれる)という場合は、この警告を無視してかまいません。数日または数か月ずれている場合は、スタック・ダンプ
・ファイルと、フォーマットに使用しているシンボル・ファイルとの間で、ビルド・レベルが一致していません。こ
の場合は、スタック・ダンプ・ファイルが報告している日付が正しい日付です。以下は、1時間のずれがある例です。
このずれは無視できます。
WARNING .date mismatch
[trapfile = 03/14/2002
WARNING .date mismatch
[trapfile = 03/14/2002
WARNING .date mismatch
[trapfile = 03/14/2002
for DB2ABIND [dbg = 03/14/2002 07:34:11]
06:34:12]
for DB2APP [dbg = 03/14/2002 07:34:10]
06:34:12]
for DB2CLI [dbg = 03/14/2002 07:34:07]
06:34:08]
Windowsのperfmonの使用
Windowsに同梱されているperfmonツールを使用すると、パフォーマンス・データやリソース使用の統計情報をキャプ
チャーできます。perfmonログのセットアップとキャプチャーの方法を理解することは、さまざまな種類の問題の調査
にとって非常に重要です。
まず注意すべき点は、入出力をモニターするにはディスク・カウンターを使用可能にする必要があるということで
す。そのためには、diskperf -y (ストライプ・セットの場合は-ye)を実行し、マシンをリブートします。
Windows 2000でログをセットアップするには
1.
2.
3.
4.
コマンド・プロンプトからperfmonを実行します。
左のフレームの[パフォーマンス ログと警告]を選択します。
[カウンタ ログ]を右クリックし、[新しいログの設定]を選択します。
設定に名前を付けて、[追加]をクリックし、パフォーマンス・カウンターを追加します。
この段階で、画面の表示は次のようになります。
[追加]、[閉じる]、[OK]の各ボタンを適宜クリックして、ウィンドウを閉じます。最初の画面に戻ったら、[カウンタ
ログ]をダブルクリックします。ログ名の左に表示されている緑のアイコンによって、ログが既に実行されていること
がわかります。まだ開始されていない場合は、ログを右クリックし、[開始]を選択します。たとえば、ログの名前
がdb2perfの場合、画面の表示は次のようになります。
ログ・ファイルを表示するには、ツリーで[システム モニタ]を選択し、[ログ ファイル データの表示]アイコンを選択
します。
ログ・ファイルを選択したら、次に、グラフにカウンターを追加する必要があります。グラフ領域を右クリックし、
目的のカウンターを追加します。以下は、設定と出力のサンプルです。このサンプルでは、[% Processor Time]カウン
ターの[すべてのインスタンス] (プロセス)が選択されています。
設定:
出力をわかりやすくするには、インスタンス(レコード)を選択し、Ctrl+Hキーを押して白で強調表示します。その後リ
ストを巡回して、不要なインスタンス(CPUの使用率が低いもの)を削除します。
魅力的な機能の1つとして、perfmonでは、DB2とシステムのパフォーマンス・カウンターを1つのログにまとめること
ができます。後の例でわかるように、この機能によって、データの関連づけが非常に簡単になります。
注意事項とシステム・データの最初の確認
初期データの収集が完了したら、システム、プロセス、DB2固有の要素などに関して、リソースの問題や異常な状態
を示す情報がないかどうかを探すことができます。システムや行われているアクティビティーについて詳しくない場
合は、以下の注意事項をよく確認しておく必要があります。
●
●
●
キャプチャーされているデータが、問題が発生しているときのデータではない可能性があります。
本来の対象とは異なる問題を示すデータがある場合があります。実際、システム上に異なる複数の問題があ
り、それらが、深刻度の異なる1つまたは複数の症状を引き起こしている場合もあります。
データが二次的な症状を指している場合があります。たとえば、最初の問題によって発生した新しい状態が第2
の症状を引き起こし、その第2の症状が最初の問題を圧倒するような場合があります。そのよい例としては、
データベース・サーバーでリソースの競合のために要求が「つかえている」ときに、アプリケーション・サー
バーが、以前にアイドル状態だった接続でさらに多くの要求をサーバーに送る場合があります。この場合、結
果として、アクティブな接続によってサーバーのメモリーが次第に占有されて、二次的な症状が発生します。
あらゆる場合において、データに含まれる意味を、最初に定義した問題に結び付けるよう心がけることが大切です。
たいていは、すぐにうまくはいきませんが、この目標を常に視野に入れておくことによって、間違った問題や、そも
そも存在さえしていない問題の解決に、無駄な時間を費やさずに済むようになります。
UNIXでは、多くの場合、問題の調査は以下の作業で始まります。
●
●
vmstatやiostatの出力で、待ち時間やアイドル時間に対してシステムCPUとユーザーCPUがどのくらい消費されて
いるのかを確認します。一般に(必ずとはいえない)待ち時間は、入出力を待っていることを表します。システ
ムCPUがユーザーCPU以上になっている場合は、必ずと言っていいほど、問題があります。
psの出力をCPUペナルティー(C)とメモリー使用率(RSS列とSZ列)の降順に並べて、最もCPUの使用率が高いプロ
セスをチェックします。以下に例を示します。
ps -elf ￨ sort +5 -rn
同じプロセスが一番上の方にあり、CPUペナルティーが60∼120の範囲にとどまっている場合は、それらのプロ
セスが常にCPUサイクルを消費していることを表しています。調査の必要があります。
Windowsでは、出力をCPUとメモリーの使用率の列で並べて、それらを最も消費しているのはどれかを確認します。
入出力の判定については、perfmonの出力がないと難しくなります。
システム・リソースの使用量に関連するDB2スナップショット要素
以下は、システム・リソースの使用量に直接対応するDB2スナップショット要素です。
データベース・マネージャー:
●
●
●
●
●
●
割り当てられているソート・ヒープ - ソートに使用されている専用メモリーの合計。
データベース・マネージャーで実行されているリモート/ローカル接続 - これらの接続は、CPUやメモリーを最
も多く消費する傾向があります。
登録されているエージェント - これらは、インスタンスdb2syscsプロセス下のオペレーティング・システム・ス
レッド(Windowsの場合)またはDB2プロセス(UNIXの場合)に対応します。
空のプールから作成されたエージェント - エージェントの作成率が高い場合、UNIXでは、プロセスをフォーク
することによってシステム・オーバーヘッドが増大します。
別のアプリケーションから流用されているエージェント - 流用率が高いと、CPUの消費が高くなる可能性があ
ります。
コミットされている専用メモリー - Windowsで、インスタンスの専用メモリーの消費に大まかに対応します。
データベース:
●
●
●
●
●
現在接続しているアプリケーション - システムの全体的な負荷の指標。
現在データベース・マネージャーで実行されているアプリケーション - これらのアプリケーションは、最も多
くのリソースを必要とします。
アプリケーションに関連付けられているエージェント - 全体的な負荷、db2syscsプロセスのオペレーティング・
システム・スレッド(Windows)、プロセス(UNIX)の指標。
割り当てられているソート・ヒープの合計 - すべてのデータベース・エージェントでソートに使用されている
専用メモリー。
バッファー・プール・カウンター - 物理読み取りと物理書き込み、読み取り時間と書き込み時間、プリフェッ
チの待ち時間は、すべて入出力アクティビティーの指標になります。
アプリケーション:
●
●
●
アプリケーションの状態がUOW Executingの場合、サーバーでなんらかの処理を行っているプロセスまたはス
レッドがあることになります(CPUで実行されているまたは実行されるのを待っている、入出力を処理している
または入出力を待っているなど)。
バッファー・プール・カウンター - 前に述べたとおり、これらは入出力アクティビティーのよい指標となりま
す。
エージェントが使用したユーザーCPU時間またはシステムCPU時間の合計 - CPUリソースの使用状況を示
し、UNIXのps出力やWindowsのスレッドのプロセッサー時間に直接関連付けることができます。スナップ
ショットの一番下のプロセスの項目は、システム・データから得たプロセスのリソースの使用状況を、アプリ
ケーションによって生成されたアクティビティーに対応付けるのに役立ちます
表スペース:
●
表スペース・スナップショットのバッファー・プール・カウンターは、特定の表スペースからのデータベース
の入出力アクティビティーを、ディスク・レベルまたはファイル・システム・レベルの入出力統計情報に関連
付けるのに役立ちます。
セクション6:パフォーマンスの問題の例
多すぎるシステムCPU
以下は、UNIXでCPUの使用を過度に増加させる方法の例です。
1. ntra_parallelismを使用可能にします。
db2 update dbm cfg using intra_parallel yes
2. エージェント・プーリングを使用不可にして、最大エージェント数を増やします。
db2 update dbm cfg using num_poolagents 0 maxagents 500
db2stop force
db2start
3. db2が1つの接続ごとに16のサブエージェントを使用するようにします。
db2 update db cfg for sample using dft_degree 16
4. 次のスクリプトを実行します。
UNIX:
db2 connect to sample
while [ 1 ]
do
db2 select ¥* from project > /dev/null
done
この構成およびアクティビティーによって、DB2によるエージェントの作成率とシステム上のプロセスの作成率が非
常に高くなります。データベース・マネージャーのスナップショットからのエージェントの作成率を、AIXのvmstat fとループ内で組み合わせることによって、データを次のように関連付けることができます。2つの数がほとんど同じ
速さで増加している点に注目してください。
Agents created from empty pool
18072379 forks (from vmstat
Agents created from empty pool
18072551 forks
Agents created from empty pool
18072814 forks
= 11994
-f)
= 12140
= 12375
vmstat 1でも同様のことが確認できます。システム呼び出しとシステムCPU時間が高くなっています。
kthr
----r b
5 3
6 3
6 2
memory
----------avm
fre
824875 249427
825602 250783
827668 248681
page
-----------------------re pi po fr
sr cy
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
faults
-----------in sy
cs
1177 16500 3077
1038 11962 2975
1046 14406 2941
cpu
----------us sy id wa
12 70 14 3
25 72 3 0
6 91 1 2
多すぎる入出力
ここでは、Windowsの例を使用します。この例では、設定が低すぎるバッファー・プールが、頻繁にヒットする表を
キャッシュしています。
1. ファイル・キャッシュを使用不可にします。
db2set DB2NTNOCACHE=YES
db2stop force
db2start
2. 1000ページを占めるようになるまでemployee表のサイズを増やします。そのためには、次のコマンドを使用しま
す。表のサイズはreorgchkで確認できます。
insert into <table> select * from <table>
3. db2 alter bufferpool ibmdefaultbp size 50
(変更内容を反映するためにデータベースをリサイクルします)。
4. perfmonを使用可能にします。[システム モニタ] (グラフ・ビュー)を選択します。次に、グラフの中を右クリッ
クし、[カウンタの追加]を選択して、以下のパフォーマンス・モニター・カウンターを選択します。
オブジェクト カウンター
Logical Disk
% Disk Time (employee表を含むディスクを選択します)
Logical Disk
Avg Disk Queue Length
DB2 Databases Bufferpool Data Physical Reads
DB2 Databases Total Bufferpool Physical Read Time
5. 次のバッチ・ファイルを使って、employee表からすべてのレコードをループで選択します。
db2 connect to sample
:begin
db2 select * from employee
goto begin
6. employee表があるディスクのビジー時間が100%になるまで、新しいCLPセッションからこのスクリプトを実行
します。
一部の変数のスケールを調整すると、グラフの出力は次のようになります。
多すぎるメモリー使用量
この例では、大きなソート・ヒープを使って、db2agentの専用メモリーの使用量が増えた状態について見てみます。
このモニター・データはSolarisから取得していますが、この症状はすべてのプラットフォームで観察できます。
1. 次のステートメントを使って、employee表を200ページくらいまで増やします。表のサイズは、reorgchkコマン
ドで確認できます。
insert into employee select from employee
2. sheapthres (データベース・マネージャー構成)を500000に増やして、ソート・モニターのスイッチをオンにしま
す。ソート・ヒープを20000に増やして、インスタンスをリサイクルします。
3. 次のステートメントをスクリプト内に配置します。
select e1.empno, e2.firstnme, e3.midinit, e4.lastname,
e5.workdept, e6.phoneno,e7.hiredate, e8.job from employee e1,
employee e2, employee e3, employee e4, employee e5,
employee e6, employee e7, employee e8 where e1.empno=e2.empno
AND e2.firstnme=e3.firstnme AND e3.midinit=e4.midinit AND
e4.lastname=e5.lastname AND e5.workdept=e6.workdept AND
e6.phoneno=e7.phoneno AND e7.hiredate=e8.hiredate AND
e8.job=e1.job order by 7,5,3,1,2,4,6,8
4. このステートメントを複数のセッションから実行し、その都度以下のコマンドをチェックします。
❍ vmstat 1
❍ /usr/bin/ps -elf | sort +9 -rn | head
❍ swap -s
❍ db2 get snapshot for database manager | grep "Sort heap allocated"
以下のようなことを確認できます。
●
●
get snapshot for database managerから、新しいセッションが追加されるたびに、割り当てられているソート・ヒー
プが∼20000ページずつ増加していることがわかります。
ps出力の大きなエージェントのSIZE (単位は4Kメモリー・ページ)は、それらのエージェントがソートのために
占有している専用メモリーでほとんど構成されています(Solarisのps出力には、エージェントによってアタッチ
されている共用メモリーが含まれますが、この構成の共用メモリーは小さくなっています)。
●
vmstat 1では、ある程度のページングや、フリー・リストの継続的な減少が確認される場合があります。ページ
ングには問題がありますが、フリー・リストが低いのはきわめて通常の状態であり、そのこと自体は何の問題
も示しません。たとえば、RAMの3%は低限界値として一般的です。ただし、一貫して0に近づいたままの場合
は問題です。
r b w swap free re mf
pi po fr de sr s0 s1 s2 s6 in sy cs us sy id
0 0 0 923320 26688 0 160
0
0 0 0 0 0 0 0 0 610 23 200 28 2 70
3 1 0 922904 22864 228 632 2720 0 0 0 0 6 0 0 0 3421 1312 1516 26 27 48
1 0 0 922576 16856 308 1284 3360 0 0 0 0 9 0 0 0 4442 2310 2137 67 33 0
最後に、ソートを実行している各セッションをキャンセルします。usr/bin/ps -elf | sort +9 -rn | headをもう一度実行し
て、セッションを終了してからSIZE列が減少しているかどうかを確認します。エージェントがまだ同じサイズのまま
なのは極めて通常の状態です。ほとんどのUNIXプラットフォームでは、プロセスはメモリー使用量の最高水準点を維
持します。
セクション7:まとめ
詳しい情報の参照先
この回は、問題の分析を始めるためのほんの序論にすぎません。
最初に正しいデータを確認するだけで解決できる(少なくとも正しい方向に進むことができる)問題もあれば、より複
雑な問題やより微妙な問題もあります。そのような問題では、複数のデータ・コレクションやより複雑な分析手法を
用いた戦略的なアプローチが要求されます。
利用できるその他のリソースを以下にいくつか紹介しておきます。
●
●
●
●
●
●
●
DB2オンライン・マニュアル
UNIXのマニュアル・ページ: ツールに関する情報が豊富に含まれています。
AIXのマニュアル
Solarisのマニュアル
HP-UXのマニュアル
Linuxのマニュアル
Windowsサポート