多くの顧客は推定処理時間を使用して短いリクエストを優先します。これを行なうために、顧客は通常、CPU使用率に基づいて各アカウントに3つのワークロードを定義します。
- 短期
- 中期
- 長期
また、ユーザーは、実行時間が長いリクエストが優先順位の低いワークロードに移動されるように、短期および中期のワークロードに対する例外を作成します。
短いリクエストを優先する別の方法として、タイムシェアの低下オプションを有効にする方法があります。このオプションは、長時間実行されるリクエストに利用できるリソースを減らします。このオプションは、タイムシェア層で実行されているすべてのリクエストに適用されます。戦術的な層またはSLG層のワークロードには適用されません。TIWMは例外を含みませんが、DBAはタイムシェアの低下オプションを使用し、リクエストの降格で同様の機能を提供できます。
タイムシェアの低下は次のように機能します。
- ワークロードおよびワークロード管理方法(層)に基づいて割り当てられているリソースへのアクセス速度でリクエストが開始されます。
- TASMは、リクエストがそのノードでCPUの10秒またはI/Oの100 MBを消費した後、そのノードのリクエストに利用できるリソースを半分にします。
- TASMは、リクエストがそのノードでCPUの200秒またはI/Oの10,000 MBを消費した後、再びそのノードのリクエストに利用できるリソースを半分にします。このアクセス速度はリクエストが終了するまで一定しています。
TASMはタイムシェアの低下を各ノードで独立して実行します。これは、別のノードの異なる低下レベルでリクエストを実行できることを意味します。
タイムシェアの低下を使用する前に、次のトレードオフを考慮してください。
- タイムシェア層のすべてのワークロードが影響を受けます。TASMでは、特定のワークロードに低下を適用することはできません。
- 低下をトリガーするしきい値は、すべてのアクセス レベルですべてのワークロードについて同じになります。最上位は下位と同じに扱われます。
- 多くの低いリクエストで低下が発生する場合、受け取るリソースが少ないために、ロックやAMPワーカー タスクを不必要に長時間保持する可能性があります。
- タイムシェアでほとんどのリクエストに自動低下が発生する場合、ほとんどのリクエストは低下が適用される前と同様に、相互に同じ相対的な優先順位となっています。
ヒント： TASMのあるシステムでは、ワークロード例外によって堅牢な調整できるオプションが提供され、変更ワークロード アクションを使用することによりタイムシェアの低下と同じ目標を達成します。TASMシステムでは、ワークロード例外はより予測可能であり、測定可能です。タイムシェアの低下はワークロード例外のないTIWMシステムに適しています。
クエリー ロギングを有効にすると、リクエストの低下のレベルがDBQLogTblのCPUDecayLevelおよびIODecayLevelフィールドに記録されます。