If you ever see system time surpass user time, either contact your system administrator or casually give your pager to your colleague and walk away. When this occurs, which is very unusual, the operating system is spending more time managing itself than doing work for you. The operating system can actually continue spending more and more time self-managing until it finally shuts down.

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%.