As a painful and humiliating as this is, I have to admit that this actually happened to me. This was during one of my consulting engagements when Oracle's multithreaded servers (MTS), commonly called shared servers, were first available. I forgot to set the instance parameter mts_max_servers. The system was very large and running a well-known financial application. The shared servers where very busy, and Oracle responded by launching new shared servers. Unfortunately, it was taking so long for the shared server processes to start that, whenever Oracle rechecked the situation, it came to the conclusion that it should launch even more shared servers (you know where this is headed). Eventually, Oracle launched so many shared servers and the operating system was so far behind and busy trying to start the processes that the operating system actually shut down. During this time of excitement, user time started dropping and system time started increasing, leading to the system becoming completely unresponsive and the console displaying "panic."

When does queuing become a problem? The answer begins with, "Well, it depends." And what it depends on, in large part, is the number of CPU cores. A general answer is queuing becomes significant when CPU cores are busier more than 75% of the time. This is truly a general statement and does not imply that you want your CPUs running below 75%.

Figures 4-3 and 4-4 are based on the same 12 CPU core model. It's easy to think that when queuing represents 10% of the response time, this is a very serious situation. However, based on queuing theory, which CPU subsystems follow very closely, at around 75% busy, queue time accounts for around 10% of the response time. Now, 10% may seem very significant, but if you look at the situation graphically in Figure 4-4, 75% busy doesn't look so bad. This demonstrates why it can be a good idea to show data both numerically and graphically.