IBM i のシステム制限を追跡する
複雑なシステムには、制限というものがつきものです。コンピューター システムも変わりありません。長年にわたって、さまざまなクライアントと作業を行ってきましたが、パフォーマンスの限界を突破するくらいに、ぎりぎりまでシステムを追い込んでいるショップを数多く目にしてきました。私が遭遇する制限には、 多種多様なものがあります。たとえば、ライブラリー内にはどれくらい多くのオブジェクトが存在することができるのか、表にはどれくらい多くの行を挿入することができるのか、IFSのファイルは、どれくらい大きなサイズにすることができるのかなど、実に様々です。
通常は、こうした制限は大きめに設定されているため、それらを気にする必要はないと思うかもしれません。特に、アップグレードを行った後にはそう思えるものです。しかし、システムのワークロードが増えると、ユーザー数であれ、トランザクション レートであれ、ワークロード ピークであれ、システム制限について把握しておく必要性も増えます。また、多数のジョブの開始や過剰なスプール ファイルの作成など、想定外の制御不能な状況がある場合も、制限は心配の種になります。
IBM i システム制限については、Knowledge Centerの「 最大処理能力 」のセクションで、リリースごとに説明が記されています。制限があることを知っていることは重要ですが、システムがこれらの制限に近付いているかどうかを知ることはさらにいっそう重要です。システムが制限に達すると、良からぬことが起こり始めます。そうした良からぬことというのは、ジョブが失敗する そこそこの良からぬ ことである場合もあれば、システムの停止のように、 本当に良からぬことである場合もあります。
システム制限への到達に潜在的にどれくらい近付いているかを把握するのに役立てるために、IBM i には システム・ヘルス・サービスが用意されています。オペレーティング システムは、自動的に主要な制限を追跡しています（すべての制限が追跡されているわけではありません）。また、システムにおけるピークを確認するのに照会することができるビューも提供されています。
概して言えば、顧客のシステムで遭遇しがちな制限は、3つあります。そのような状況が発生すると、問題解決のための急を要する仕事が発生してしまいます。以下に、一般に思われているよりも頻繁に見られる制限の問題の例を示します。
- ジョブの最大数
この問題が起こるのを目にするのは、ジョブがジョブ ログを生成するか、またはジョブに保留ジョブ ログがある場合に、過剰な数のジョブを開始している制御不能な状況です。これらのジョブ ログは、システムにそのジョブを保持しています。 - システムASPにおけるスプール ファイルの最大数
スプール ファイルは、誰もが好きなようです。しかし、システムASPには、260万のスプール ファイルというハード リミットがあり、この制限に達すると、まずい状況になります。ジョブ ログがこの問題の大きな原因となることがよくあります。私は、QDFTSVRジョブ記述がLOG(4 0 *SECLVL)へ変更されている最新のアカウントで作業しましたが、これをやってはいけません。このロギング レベルでは、事前開始ジョブが再使用されるたびに、ジョブがユーザー プロファイルをスワップするときにジョブ ログが作成されます。ジョブ ログが膨大な数になってしまう場合があります。 - テーブル内の行の最大数
際限なくテーブルに行を追加しながら、古いレコードを削除しないでいると、最終的にはこの制限に達することになります。際限のない量のデータを保管しなければならない場合は、何らかのアーカイブのプロセスを用意する必要があります。
これら3つの制限は、システムが自動的に追跡しているタイプの制限の例です。システム・ヘルス・サービス機能は、これらの制限への到達に潜在的にどれくらい近付いているかについて把握する方法を提供しています。さらに多くの制限が追跡されていますが、ここで説明した3つの制限は、どのIBM i のショップにとっても重要であるはずです。
これらの制限は、 QSYS2.SYSLIMTBLテーブルで追跡されています。制限は、下限（floor）および増分（increment）という構成値に基づいて記録されます。下限は、システムが制限の追跡を開始する下側のレベルであり、増分は、その制限がどれくらい増減したときに、再びSYSLIMTBLで追跡されるようになるかを指定する分量です。追跡される制限の下限および増分については、Knowledge Centerの「 システム・ヘルス・サービス 」のセクションに説明が記されています。このテーブルにAFTER INSERTまたはAFTER DELETEトリガーを追加することができます。これを使用すると、制限が記録されているときに通知を送信するなどのアクションを実行することができます。SYSLIMTBLに関するIBMのドキュメンテーションには、トリガーを使用して区画内の最大行数を検査する例が紹介されています。
通常は、SYSLIMTBLではなく、 QSYS2.SYSLIMITS ビューを照会します。SYSLIMITSビューには、システム制限についての情報と、その他のシステム情報、制限をログに記録したジョブ、およびそのジョブについての情報（そのジョブがまだアクティブな場合）が含まれています。また、 QSYS2.SYSLIMITS_BASIC ビューという別のビューも使用できます。このビューでは、制限をログに記録したジョブについての情報が含まれないため、パフォーマンス オーバーヘッドを減らすことができます。
ここで、IBM提供の例を使用して、システム制限の知識をどのように活用できるかについて説明しようと思います。このSQLの例は、QMAXJOBシステム値と比較する形でジョブの最大数を表示することはできるのかと、IBMのScott Forstie氏に尋ねたときに彼が作成してくれた例です。これは非常に重要な比較です。というのも、文書化されているジョブの最大数は970,000ですが、実際の区画のジョブの最大数を定義しているのはQMAXJOBシステム値であるからです。
WITH TT(JOB_MAXIMUM)
AS (SELECT CURRENT_NUMERIC_VALUE
FROM QSYS2.SYSTEM_VALUE_INFO
WHERE SYSTEM_VALUE_NAME = 'QMAXJOB')
SELECT LAST_CHANGE_TIMESTAMP AS INCREMENT_TIME, CURRENT_VALUE AS JOB_COUNT,
TT.JOB_MAXIMUM,
DEC(DEC(CURRENT_VALUE,19,2) / DEC(TT.JOB_MAXIMUM,19,2) * 100,19,2)
AS PERCENT_CONSUMED
FROM QSYS2.SYSLIMITS, TT
WHERE LIMIT_ID = 19000 ORDER BY CURRENT_VALUE DESC;この照会は、以下のスクリーン キャプチャーと同じような結果を返します。このテスト システムでは、QMAXJOBシステム値は970,000に設定されていました。QMAXJOBをより小さい値に設定している場合は、その設定値が使用されます。結果はCURRENT_VALUE（すなわち、JOB_COUNT列）順に並べられ、追跡された現行ジョブ数が示されます。ORDER BYをLAST_CHANGE_TIMESTAMPに変更すると、経時的な使用量を確認することもできます。PERCENT_CONSUMED列を見れば、ジョブ数がQMAXJOBシステム値までどれくらい近付いたかについてすぐに把握できます。
IBMは、システムがどのようにSYSLIMTBLテーブルを整理するかを制御するのに使用できる、いくつかの グローバル変数 を提供しています。行を保持する日数を指定したり、制限のタイプごとに保持する行数を規定したりすることによって、テーブルの整理方法を制御することができます。これらのグローバル変数のいずれかの値を変更して、特定のニーズに合わせてSYSLIMTBLの整理方法をカスタマイズすることができます。
システム・ヘルス・サービスには、これらの制限のいくつかに対する組み込みの アラート機能 と、システムがこれらの制限に対するアラートをいつ送信するか（デフォルトは最大値の90%）を定義するためのグローバル変数が用意されています。このアラートは、実際は、SQL7062メッセージであり、QSYSOPRメッセージ待ち行列に送信されます。システムは、毎日1回、収集サービスが循環されるときに、これらのしきい値設定を検査するのみであるため、タイムリーな通知であるか心配な場合は、上述のトリガーを使用するオプションの方が適切でしょう。
なお、「SQLスクリプトの実行」には、システム・ヘルス・サービスも含めて、すべてのIBM i サービスの例が用意されていることはご存じでしょうか。
また、上述の例を提供してくれた、Db2 for iビジネス アーキテクトのScott Forstie氏は、 システム制限についてのより詳細な情報が記されたプレゼンテーションを提供しています。トリガーおよびSQL照会を使用してシステム制限情報を確認する例なども数多く紹介されていますので、参照してみることをお勧めします。
