Step One: Underestimate the size of the memory by 50%.
Step Two: Using that measurement, allocate a quarter of what you think the server has in memory to a MySQL query cache, and the other half to various other caches in MySQL and Apache.
Step Three: ab -kc 50 -t $((5*60)) http://the.server/

In about thirty minutes, when I could actually enter text at the keyboard again, I discovered the folly, adjusted the sizes, and ordered more RAM. During that thirty minutes, however, I was about to die. I’d cancelled the benchmark around thirty seconds into it when I noticed no progress and the fans in the G5 started to sound like La Guardia’s runway around mid-day. It didn’t let up for a half-hour more.

After some careful listening, I heard the hard drive through the fans. It was the lovely sound of VM thrashing as it moved Apache and MySQL around a few hundred times to get the very first queries done, it would appear.

Bad VM implementation, bad.

When it came up, I started to ramp the connections. I started at ten, then fifteen, then twenty. Around forty connections the G5 bit it again, even with the right memory sizes. I’m going to have to toy with that when I get back to work. It doesn’t make much sense. Apache is setup for up to 100 connections, half persistent. MySQL has 64M of query cache, 8M for keys, and 2M for sort. There’s nothing else running.

Grr. Arg.