パフォーマンスに問題が発生した場合、実行計画の原因を除外できるならば、その可能性は高いですが、容量問題である可能性が高いです。V$OB_SQL_AUDITビューを使用して容量問題かどうかを判断します：QUEUE_TIMEが明らかに増加し、明確な論理読み取りやEXECUTE_TIMEの時間消費が増加するSQLが存在しない場合。最適化されていない計画の問題では、明らかな論理読み取りとEXECUTE_TIMEの時間消費が増加するSQLが見られ、EXECUTE_TIME部分は主にCPU時間の増加です。
説明
V$OB_SQL_AUDITの詳細については、V$OB_SQL_AUDIT(Oracleモード)およびV$OB_SQL_AUDIT(MySQLモード)を参照してください。
以下のシナリオで発生する可能性があります：
アプリケーショントラフィックの増加
TopSQLの実行計画に明らかな変更がなく、テナントのCPU利用率が増加し、SQL実行回数も増加している場合、アプリケーショントラフィックの増加によるパフォーマンス問題である可能性が高いです。
アプリケーションワークロードの変化
アプリケーショントラフィックの増加とは異なり、アプリケーションのワークロードに変化が生じた場合、例えば大規模リクエストの割合が増加した場合などです。
インフラ層での計算リソースの競合
この問題に対しては、以下の方法で解決できます：
テナントのCPUスペックを調整する
クラスタパラメータを調整する
クラスタパラメータ
cpu_quota_concurrencyは、テナントのCPUが提供するワーカースレッド数を制御するために使用されます。テナントの最小ワーカースレッド数 =cpu_quota_concurrency*MIN_CPU。テナントに容量問題が発生した場合、物理マシンのCPU負荷がそれほど高くない場合、ほとんどのワーカースレッドが実際にはCPUリソースを使用していないことを意味します。このパラメータを調整することで、物理マシンの計算リソースをさらに圧縮できます（このパラメータ値はあまりにも大きくてはなりません。過大な値は頻繁なコンテキストスイッチやスレッドの頻繁な作成・破棄によるシステムの問題を引き起こす可能性があります）。説明
cpu_quota_concurrencyは、テナントの各CPUクォータで許可される最大並列数を設定します。詳細については、cpu_quota_concurrencyを参照してください。SQLのリミット
注意
容量問題が発生した場合、一般的にはスケールアップ（テナントのCPUスペックを引き上げるか、cpu_quota_concurrencyを引き上げる）によって解決します。ワーカースレッドが増加すると使用するメモリリソースも増加するため、テナントのメモリスペックも同時に引き上げる必要があります。