NEWS
できるIBM i 7.4解剖 できるIBM i 7.4解剖
2021.04.23

【できるIBM i 7.4解剖】第9回 「Db2 for iのODBC/JDBCサーバージョブ QZDASOINITのパフォーマンス調整」

【できるIBM i 7.4解剖】第9回 「Db2 for iのODBC/JDBCサーバージョブ QZDASOINITのパフォーマンス調整」

投稿日:2021年4月23日

日本アイ・ビー・エム(株)
Power Systems テクニカル・セールス
佐々木 幹雄

今回はODBC/JDBCサーバージョブとしてクライアントからのSQLリクエストを処理するQZDASOINITについて解説致します。ODBCサポートの基本については前回解説していますので合わせてご覧ください。

ODBC/JDBCのサーバーサイドジョブ

ODBC/JDBCのSQLアクセスを処理するサーバージョブ(デーモン)がQZDASOINITです。デフォルトではQUSRWRKサブシステム起動時に2つのQZDASOINITジョブ(事前開始ジョブ Pre-Start Job)が起動します。(図1)
QZDASOINITはDB接続のコネクションプールとして機能し、通常複数個のジョブが常駐しクライアントからのリクエストに応答します。デフォルトでは2つジョブが起動していますので同時に3つ以上のODBC/JDBCリクエストが発生するとQZDASOINITのジョブが追加起動します。


▲ 図1:IBM i ODBCサポート

Db2 for iのODBC/JDBCアクセスでのパフォーマンス調整について

Db2 for iへのODBC/JDBCアクセスする際、パフォーマンスが思ったようにでない、という状況が発生した場合、原因はいろいろと考えられます。よくある問題としてはSQLに必要な最適なインデックスが作成されていないケース、アプリケーションコードの問題(不適切なSQL構文、ハードオープン・クローズが多発、等様々な要因)、前回説明したODBCドライバーのブロックサイズ設定などがあるかと思います。インデックスやブロックサイズはアプリケーション毎に最適値が異なり汎化がむつかしいので、ここではIBM i上のODBC/JDBCサーバージョブQZDASOINITのジョブ数について解説致します。
まず、QZDASOINITジョブの特徴は以下の通りです。(図2)


▲ 図2:QZDASOINITジョブの特徴

-QZDASOINITはじめサーバージョブの開始はCPUコストが高い処理です。QZDASOINITを追加で起動する操作はシステム負荷が高く結果レスポンスタイム等パフォーマンスに影響を及ぼす事があります。
-QZDASOINITはシステムIPL時(サブシステム開始時)に指定されたジョブ数(デフォルトは2つ)を起動しておき、実際のユーザーからのアクセス時パフォーマンスが低下しないように考慮されています。
-一方でQZDASOINITジョブの実行中は同期I/O処理が定常的に発生してしまいます。同期I/O処理はシステム負荷、特にI/O負荷(IBM iではHDD等のアームビジー率)に影響を与えるため、無用に多く起動することは推奨されません。 -IPL時に起動されるQZDASOINITのジョブ数(デフォルトは2つ)と実際に利用するODBCクライアント数の差が大きいと、ユーザーリクエストが発生した時点で追加のQZDASOINITジョブ起動が多数発生しパフォーマンス劣化を引き起こす可能性があります。
以上から一般的な考え方としては、ピーク時のODBC/JDBCクライアントから同時実行数や、最も一般的な時間帯のODBCクライアント数と同数程度QZDASOINITジョブを起動しておくことが最良なシステムパフォーマンスを発揮する可能性が高いと考えられます。

QZDASOINITジョブの実行状況確認

ここではまず、現在稼働しているQZDASOINITジョブを確認してみましょう。5250画面からDSPACTPJコマンドを実行します(図3)。

		DSPACTPJ SBS(QUSRWRK) PGM(QZDASOINIT)


▲ 図3 : DSPACTPJコマンド

(1) 経過時間:IPL以降(サブシステム開始以降)またはF13キーを押下後に経過した時間。
(2) 現在実行中のジョブ数。図中では20です。
(3) (1)の経過時間中に測定された最大ジョブ数。図中では25です。
(4) 現在使用中のジョブ数。図中では2です。
(5) (1)の測定時間中に測定された平均の使用ジョブ数。図中では1.0です。
(6) (1)の測定時間中に測定された最大の使用ジョブ数。図中では24です。

ア)

平均リクエスト数は⑤から1と分かります。平均的な接続数に合わせてQZDASOINITジョブ数を調整するならIPL時(サブシステム起動時)の事前開始ジョブ数は1が最適であると考えられます。(後述するCHGPJEコマンドで調整します)

イ)

一方で同時リクエスト数の最大数は24です。ア)に従って事前開始ジョブ数を1に設定すると、ピーク時には2つ目のジョブ以降を処理するために23個のジョブを追加で起動する必要が発生しえます。前述したとおりQZDASOINITジョブを新たに起動するシステムコストは高く、CPU負荷や2つ目以降のジョブのレスポンスタイムに大きく影響を与える可能性があります。同時リクエスト数のピーク時に合せて調整するのであれば24に近い値に合せるのが正解と考えられます。

ウ)

ただし、イ)の考え方にはデメリットがあります。平均的な同時リクエスト数は1ですので、大半の時間帯においては明らかに過剰なQZDASOINITジョブ数が起動していることになります。QZDASOINITジョブは同期I/Oを発生しますのでシステムのI/O負荷を無駄に高くしてしまう、という事が言えます。このような場合、WRKDSKSTSコマンドやNavigator for i などでディスク稼働率を監視(確認)し、アームビジー率が許容範囲か確認する必要があります。もし、アームビジー率に懸念があるなら(あるいはシステムのI/O処理時間が遅延傾向にあるなら)QZDASOINITジョブ数を減らす事が最善の設定となるでしょう。

以上の設定について補完的な情報をDSPACTPJコマンドは提供します。先のDSPACTPJコマンドの画面で次ページを表示します(図4)。


▲ 図4: DSPACTPJコマンド 次頁

この画面ではクライアントからのODBC/JDBC接続要求に待機状態の発生有無やその平均時間が表示されます。図4の例はテスト環境のため待機状態(QZDASOINITジョブ数がクライアントからの同時接続要求に対して不足している状態)は発生していません。待機中の現在数、平均数、ピーク時の数、拒否された数にカウントがあれば不足状態が発生したことになります。待機状態が発生することがすべてのケースで悪い、という事にはならないと考えられますがQZDASOINITジョブ数を調整する指標になると思われます。

現在のQZDASOINITジョブ数の設定確認

前述のDSPACTPJコマンドの確認結果から開始ジョブ数を調整する必要が判明した場合、CHGPJEコマンドで開始ジョブ数を調整できます。その前に現在の設定値を確認しておきましょう。 現在のQZDASOINITジョブの設定を確認するには以下の手順で行います。

	DSPSBSD SBSD(QUSRWRK)コマンド → 10.事前開始ジョブ項目 → QZDASOINIT のOPT.欄に5(詳細の表示)

図5が表示されます。


▲ 図5:QZDASOINIT属性の確認

  • 初期ジョブ数 IPL時(またはサブシステム起動時、STRPJコマンド実行時)に開始されるジョブ数。図5では20です。
  • しきい値 図5では同時リクエスト数が20から1つ増えた時に追加のQZDASOINITジョブが追加起動されます。また、追加されるジョブ数は 追加のジョブ数に指定された 2つです。
  • ジョブの最大数 同時に活動状態にできるQZDASOINITジョブ数を指定。1~32,000または*NOMAXを指定
  • 最大使用数 1つのQZDASOINITジョブで最大、何回ユーザーからのリクエストを処理できるかを指定します。指定回数に達するとそのQZDASOINITジョブは終了されます。1~1,000または*NOMAXを指定

一般的な環境では初期ジョブ数の調整だけで十分だと思われますが、必要に応じて上記のパラメーターも調整を検討してください。

QZDASOINITジョブの調整

CHGPJEコマンドでQZDASOINTジョブ数の調整を行います。(図6)


▲ 図6:CHGPJEコマンド

初期ジョブ数を調整する場合は、初期ジョブ数 INLJOBSパラメーターを変更してください。CHGPJEコマンドは即時で変更が適用されます。
変更後、前述の手順でQZDASOINITジョブの設定値を確認してください。

API QWTRAPJSを使ったQZDASOINITジョブ数の監視

IBM i 7.4では以上で説明しようなQZDASOINTジョブ数の監視をAPI QWTRAPJSで可能となりました(図7)。


▲図7:API QWTRAPJS (Retrieve Active Prestart Jobs Status)

API QWTRAPJSのパラメーターは図8の通りです。


▲図8:API QWTRAPJS パラメーター

API QWTRAPJSを使用すれば先に説明したDSPACTPJコマンド等による監視の仕組みをプログラム化したり、運用監視に組み込んだりすることが可能となります。 システムで適切なタイミングでこのAPIを実行しQZDASOINITジョブ数を最適に制御することが可能となり、結果ODBC/JDBCのパフォーマンスの最適化とシステム負荷の最適化を実現することができると思われます。このAPIはQZDASOINIT以外の事前開始ジョブも利用可能なため様々なサーバージョブの監視、調整に役立てることができるでしょう。

いいねと思ったらシェア
twitter
facebook
hatena
できるIBM i 7.4解剖 目次を見る

この連載は…

できるIBM i 7.4解剖
関連記事
【できるIBM i 7.4解剖】 第13回「IBM i 7.4操作・運用あれこれ」
【できるIBM i 7.4解剖】 第13回「IBM i 7.4操作・運用あれこれ」
【できるIBM i 7.4解剖】第12回 <br>「IBM i – IBM i 間のネットワークファイル共有機能 QFileSvr.400」
【できるIBM i 7.4解剖】第12回
「IBM i – IBM i 間のネットワークファイル共有機能 QFileSvr.400」
あなたにオススメの連載
できるIBM i 7.4解剖
14記事
できるIBM i 7.4解剖
IBM i の”新”必須言語 〜FFRPG入門〜
14記事
IBM i の”新”必須言語 〜FFRPG入門〜
Windows10待ったなし!どうする5250徹底検証
4記事
Windows10待ったなし!どうする5250徹底検証
PAGE TOP