I had a funny thing happen today. I had recently participated in a forum thread about library cache: mutex X waits. In that discussion the library cache: mutex X waits were on an AWR report but when we dug deeper we realized it was because the database server’s CPU was totally pegged out and overloaded.
Today, I saw the same thing on one of my own servers. Here are the top 5 events:
|Event||Waits||Time(s)||Avg wait (ms)||% DB time||Wait Class|
|db file sequential read||3,188,834||21,758||7||3.55||User I/O|
|library cache: mutex X||4,260||8,943||2099||1.46||Concurrency|
|log file sync||1,226,545||4,562||4||0.74||Commit|
|latch: cache buffers chains||21,097||4,281||203||0.70||Concurrency|
Notice how small a percentage of the DB time these top events are. This is because most of the time is spent waiting on the CPU queue. Here was the load when I checked it:
11:35am up 268 days, 13:27, 4 users, load average: 14.40, 14.52, 14.76
This server has 2 cores so a load of 14 means a lot of queuing.
The operating system statistics on the AWR report show the same thing – a load of 15 and a lot of OS_CPU_WAIT_TIME.
Operating System Statistics
- *TIME statistic values are diffed. All others display actual values. End Value is displayed if different
- ordered by statistic type (CPU Use, Virtual Memory, Hardware Config), Name
So, I thought I would post this so people could see what an AWR report looks like when the cpu it totally pegged out and queuing big time. Note that the AWR report was from 1 am to 3 pm so the starting load was low but the ending load during the afternoon was at 15.