Java Reference
In-Depth Information
If the measurement involves a server-style application that accepts requests from some
source, then there may be idle time because no work is available: for example, when a web
server has processed all outstanding HTTP requests and is waiting for the next request. This
is where the average time comes in. The sample vmstat output was taken during execution
of an application server that was receiving one request every second. It took 450 ms for the
application server to process that request—meaning that the CPU was actually 100% busy
for 450 ms, and 0% busy for 550 ms. That was reported as the CPU being 45% busy.
Although it usually happens at a level of granularity that is too small to visualize, the expec-
ted behavior of the CPU when running a load-based application is to operate in short bursts
like this. The same macro-level pattern will be seen from the reporting if the CPU received
one request every half-second and the average time to process the request was 225 ms. The
CPU would be busy for 225 ms, idle for 275 ms, busy again for 225 ms, and idle for 275 ms:
on average, 45% busy and 55% idle.
If the application is optimized so that each request takes only 400 ms, then the overall CPU
usage will also be reduced (to 40%). This is the only case where driving the CPU usage
lower makes sense—when there is a fixed amount of load coming into the system and the ap-
plication is not constrained by external resources. On the other hand, that optimization also
gives you the opportunity to add more load into the system, ultimately increasing the CPU
utilization. And at a micro level, optimizing in this case is still a matter of getting the CPU
usage to 100% for a short period of time (the 400 ms it takes to execute the request)—it's
just that the duration of the CPU spike is too short to effectively register as 100% using most
Java and multi-CPU usage
This example has assumed a single thread running on a single CPU, but the concepts are the
same in the general case of multiple threads running on multiple CPUs. Multiple threads can
skew the average of the CPU in interesting ways—one such example is shown in Chapter 5 ,
which shows the effect of the multiple GC threads on CPU usage. But in general, the goal for
multiple threads on a multi-CPU machine is still to drive the CPU higher by making sure in-
dividual threads are not blocked, or to drive the CPU lower (over a long interval) because the
threads have completed their work and are waiting for more work.
In a multithreaded, multi-CPU case, there is one important addition regarding when CPUs
could be idle: CPUs can be idle even when there is work to do. This occurs if there are no
threads available in the program to handle that work. The typical case here is an application
with a fixed-size thread pool that is running various tasks. Each thread can execute only one
task at a time, and if that particular task blocks (e.g., is waiting for a response from the data-
Search WWH ::

Custom Search