Idleness Is Not Waste

A common fallacy is to view all idle CPU cycles as wasted server capacity. It's not unusual for management and various bean-counters to display a reluctance to procure new hardware if unused cycles are clearly observable on existing hardware. This puts the pressure on sys admins to reduce idleness. Such is often the case during consolidation efforts: cram as many apps as possible onto a server to soak up every remaining CPU cycle.

All performance analysis and capacity planning is essentially about optimizing resource usage under a particular set of constraints. The fallacy is treating maximization as optimization. This mistake is further exacerbated if only one performance metric, i.e., CPU utilization, is taken into account: a common situation promoted by the superficiality of performance dashboards. Maximization doesn't necessarily mean 100% utilization, either. The same is true even if some amount of CPU capacity is retained as headroom for workload growth. The tendency to "redline" it can still prevail.

You can't optimize a single number. Server utilization has to be optimized with respect to other measures, e.g., application response-time targets. We know from simple queueing theory that response time increases nonlinearly (the proverbial "hockey stick") with increasing server utilization. If the response-time goals are being met at 10% CPU busy, pre-consolidation, then almost certainly they will be exceeded at higher CPU utilization, post-consolidation. The response-time metric is an example of a cost that has to be taken into account to satisfy all the constraints of the optimized capacity plan.

Maximizing server utilization is as foolhardy as maximizing revenue. Both goals look attractive on their face, but if you don't keep track of outgoing CapEx and OpEx costs incurred to generate revenue, you could lose the company!

Guerrilla Classes for 2011

The Guerrilla training schedule for 2011 has now been finalized.



Book early, book often!

Season's Greetings 2010

As the last post for 2010, from my original home Downunder, I would just like to thank all my readers and Guerrilla class alumni during this holiday season (whichever one you celebrate) and offer you my best wishes for success in the new year.

The Melbourne office of Performance Dynamics in Australia

Unfortunately, computer performance analysis and capacity planning doesn't extend to improving the weather in the northern hemisphere. All hate-mail should be sent to Prime Minister Julia Gillard.

Reporting Standard Errors for USL Coefficients

In a recent Guerrilla CaP Group discussion, Baron S. wrote:

....
BS> Using gnuplot against the dataset I gave, I get 
BS>    sigma   0.0207163 +/- 0.001323 (6.385%) 
BS>    kappa   0.000861226 +/- 5.414e-05 (6.287%) 

The Gnuplot output includes the errors for each of the universal scalability law (USL) coefficients. A question about the magnitude of these errors also arose in a recent talk I gave. Typically, this question doesn't come up because there's more focus on assessing the residual errors as a measure of fit for the USL against the data set. Also, statistical accuracy can be a bigger issue when there are only a small number of samples. Barron reported 32 data points, so that's not an problem in this case.

Efficient Elevators: Algorithms, Cars and Queues

The latest PBS NOVA episode entitled "Trapped in an Elevator" is based on an actual event that occurred in 1999. Watching it reminded me that elevators (or lift in British english) can be regarded as a queueing system, viz., priority queues, which are also the basis for scheduling algorithms in operating systems and storage devices. A lot of this background can be found in Don Knuth's erudite volumes:

• Vol 1, p.280: elevator simulator program based on doubly-linked lists
  
• Vol 3, p.150: elevator scheduling as priority queues
  
• Vol 3, p.357: tape sorting reformulated as single elevator problem
  
• Vol 3, p.374: disk seeks treated as single elevator problem

[Best wishes for Randall's fiancée]

Cooking Up Some Hotsos for 2011

Just got word that my proposed presentation "Brooks, Cooks and Response Time Scalability" has been accepted for the Hotsos Symposium, March 2011 in Dallas, Texas.

Hotsos is a great conference that is Oracle-related but not Oracle-sponsored. As the name implies, the focus is on the performance of Oracle databases and applications, but it's been my experience that attendees are very keen to know about performance techniques, not matter what their context.

Hotsos 2011 will give me an opportunity to expand on my Nov 2007 observation that the USL contains a representation of the mythical man-month. In other presentations I've always talked about characterizing throughput scalability, but this time I'll extend the USL to quantifying response-time scalability.

Plan for Guerrilla Capacity Planning in November

You can still pile into the final Guerrilla Capacity Planning (GCaP) class for 2010 at the Early Bird rate. Before signing up, you can review the highlights of the May GCaP class. If you came to the August GDAT class, but missed the previous GCaP class, here is your chance to catch up.


As usual, it will be held at our lovely Larkspur Landing location. Click on the image for booking information.

Attendees should bring their laptops, as course materials will only be provided on CD or flash drive. We will be distributing free notepads so you can also take hand-written notes. The venue also has free wi-fi to the internet.