容量の問題

パフォーマンスの問題が発生した場合、実行計画の原因を除外できる場合は、おそらく容量の問題である可能性が高くなります。V$OB_SQL_AUDIT ビューを使用して容量の問題かどうかを判断します：QUEUE_TIME が明らかに増加し、顕著な論理読み取りや EXECUTE_TIME の所要時間が増加するSQLが存在しない場合は容量の問題です。最適でない計画の問題では、顕著な論理読み取りや EXECUTE_TIME の所要時間が増加するSQLが見られ、EXECUTE_TIME の大部分はCPU時間の増加によるものです。

以下のシナリオで発生する可能性があります：

• アプリケーショントラフィックの増加

  TopSQLの実行計画に顕著な変化がなく、テナントのCPU利用率が上昇し、SQLの実行回数が増加している場合、アプリケーショントラフィックの増加が原因である可能性が高いです。

• アプリケーション負荷の変化

  アプリケーショントラフィックの増加とは異なり、アプリケーションのワークロードが変化した場合、例えば大規模なリクエストの割合が増加した場合です。

• インフラ層での計算リソースの競合

この問題に対処する方法は以下の通りです：

• テナントCPUスペックの調整

• クラスタパラメータの調整

  クラスタパラメータ cpu_quota_concurrency は、テナントCPUが提供するワーカースレッド数を制御します。テナントの最小ワーカースレッド数 = cpu_quota_concurrency * MIN_CPU。テナントに容量の問題が発生した場合、物理サーバーのCPU負荷が高くなければ、多くのワーカースレッドが実際にはCPUリソースを使用していないことを意味します。このパラメータを調整することで、物理サーバーの計算リソースをさらに引き出すことができます（このパラメータ値は大きく設定できません。値が大きすぎると、頻繁なコンテキストスイッチングやスレッドの頻繁な作成・破棄によりシステムに問題が発生する可能性があります）。

  説明

  cpu_quota_concurrencyは、テナントの各CPUクォータが許可する最大同時実行数を設定します。詳細については、cpu_quota_concurrencyを参照してください。

• SQLのレート制限