容量問題

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

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

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

  TopSQLの実行計画に明らかな変化がなく、テナントのCPU利用率が上昇し、SQLの実行回数が増加している場合、おそらくアプリケーショントラフィックの増加によるパフォーマンス問題です。

• アプリケーションワークロードの変化

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

• インフラ層でのコンピューティングリソースの競合

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

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

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

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

  説明

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

• SQLのレート制限