API-BridgeやMONO-X Oneが実行したSQLにより、基幹業務がパフォーマンスダメージを受けないようにしたい場合の参考例となります。
(1)IBM i (AS400) のCPU割当ては、実行プライオリティ(Execution Priority)とメモリー活動化レベルで制御
例えば、基幹業務を、対話型(実行プライオリティ=20)、バッチ(実行プライオリティ=50)で稼働している場合、
API-BridgeやMONO-X Oneの投入のSQLを実行プライオリティ=51で動かせば、基幹への影響を最小化することが可能かと思います。
この場合、夜間のバッチが数十多重とかで動く場合、API-BridgeやMONO-X One投入のSQLへのCPUサービスが大幅に低下する可能性があります。
これをどうしても許容できない場合は、API-BridgeやMONO-X One投入のSQLの実行プライオリティをバッチと同じ50にする必要があります。
同じ50のプライオリティでは、ダイナミックプライオリティ*1が働き、基幹のI/OバウンドJOBに優先権を与えることができます。
*1 ダイナミックプライオリティ=TIME SLICE毎に0.008(=125分の一)ずつCPUバウンドJOBのプライオリティが下がる機能
(2)API-BridgeやMONO-X One投入のSQLが極端に多く、基幹への影響が懸念される場合
- API-BridgeやMONO-X One投入のSQLのサブシステムのメモリー活動化レベルを「*NOMAX」ではなく「10」とかに制限し、10を超えるものはSWAP OUTし実行を抑制する。
- LPARの割当コアを1コア増強し、API-BridgeやMONO-X One投入のSQLのジョブは増強1コア分以内でうごくようにCPU割当を制限。(ワークロード・グループ機能)
【参考】
コメント
0件のコメント
サインインしてコメントを残してください。