CPU使用率が高くなってくると、プロセス(スレッド)がCPUを待つランキュー待ち時間が増えます。vmstatのr列などを見ればすぐにわかりますが、Oracle Database の性能分析で AWR レポートやStatspackレポートしか情報がないといった場合は以下のような兆候から読取ることができます。
- DB Time が DB CPU + non-idle wait time より長くなる
- 待機イベントでの待機時間にランキュー待ち時間が含まれる*1
- AWRレポートの Host CPU セクションの Load Average の値が大きくなる
- load average はざっくり言うと一定期間のCPU待ちプロセス(スレッド)数(vmstatのr列) + I/O待ちプロセス(スレッド)数(vmstatのb列) の平均値です。
- AWRレポートの Operating System Statistics セクションや V$OSSTAT の OS_CPU_WAIT_TIME の値が大きくなる。
脱線しますが、Oracle Database のプロセス(スレッド)がメモリにアクセスしたときに、そのページがページアウト(メモリからディスクに退避)されていて(メジャーフォルト)、ディスクからメモリにページインされると、メモリアクセスのみ(ディスクI/Oしない)で済むConcurrency系(に限らないが)の待機時間が延びたりすると思います。
参考
Essentially, we want to fill in this equation with actual values:
db time = cpu consumption time + non idle wait time + gap time gap time = os cpu run queue time + truer gap time db time = cpu consumption time + non idle wait time + os cpu run queue time + truer gap time...
My experiment demonstrated a situation where the Oracle database time did not equal all the Oracle foreground process CPU consumption plus all the non idle wait time. The objective of my experiment was to better understand this time difference ("gap" time) and to understand how OS CPU run queue time was involved.
http://blog.orapub.com/20150304/How-OS-CPU-Run-Queue-Time-Relates-To-Oracle-Database-DB-Time.html
The experiment placed an increasing logical IO load on an Linux Oracle 12c system until the operating system CPU utilization exceeded 90%. The load was increased 18 times. During each of the 18 loads, I gathered 31 three minute samples. Each sample contains busy time (v$osstat), idle time (v$osstat), logical IO (v$sysstat "session logical reads"), non-idle wait time (v$system_event where wait_class != 'Idle'), DB CPU (v$sys_time_model), background cpu time (v$sys_time_model), database time (v$sys_time_model DB time) and the sample time (dual table current_timestamp).
http://blog.orapub.com/20150210/What-Is-Light-Green-Oracle-Database-CPU-Wait-Time.html
ここで注目したいのは、CPUリソース不足により、結果の返信までの時間が伸びることと、待機イベントの時間が大きくなることです。待機イベントを計測しているOracle(のプロセス)自体がCPUリソース不足により動けないわけですから、大きな値になってしまっても仕方ありません。待機イベントが大きくなったからといって、単純に「DB(もしくはSQL)チューニングが必要だ」と思わないでください。これも、 パート1の冒頭で「待機イベントが大きければDBチューニングとは限らない」と書いた理由の1つです。
門外不出のOracle現場ワザ 第1章
表8-3 V$OSSTAT統計情報
V$OSSTAT
OS_CPU_WAIT_TIME プロセスが準備完了状態で、オペレーティング・システムのスケジューラによる実行を待機中の合計待機時間(1/100秒)
- AWR レポートリファレンス (1) -- サマリ(KROWN:136574) (Doc ID 1746793.1)
*1:これは分析時にはわからないですが、全般的に待機イベントの平均待機時間が延びているときは疑わしいと言えるかもしれません