Aaron,
> I do consulting, so they're all over the place and tend to be complex. Very
> few fit in RAM, but still are very buffered. These are almost all backed
> with very high end I/O subsystems, with dozens of spindles with battery
> backed up writethrough cache and gigs of buffers, which may be why I worry
> so much about CPU. I have had this issue with multiple servers.
Aha, I think this is the difference. I never seem to be able to get my
clients to fork out for adequate disk support. They are always running off
single or double SCSI RAID in the host server; not the sort of setup you
have.
> What my CPU tends to be doing is a combination of general processing,
> complex SQL processing: nested loops and sorting and hashing and triggers
> and SPs.
I haven't noticed SPs to be particularly CPU-hoggish, more RAM.
> I'm curious about you having flat CPU, which is not my experience. Are your
> apps mature and stable?
Well, "flat" was a bit of an exaggeration ... there are spikes ... but average
CPU load is < 30%. I think the difference is that your clients listen to
you about disk access. Mine are all too liable to purchase a quad-Xeon
machine but with an Adaptec RAID-5 card with 4 drives, and *then* call me and
ask for advice.
As a result, most intensive operations don't tend to swamp the CPU because
they are waiting for disk.
I have noticed the limitiations on RAM for 64 vs. 32, as I find it easier to
convince a client to get 8GB RAM than four-channel RAID with 12 drives,
mostly because the former is cheaper. Linux 2.4 + Bigmem just doesn't cut
it for making effective use of > 3GB of RAM.
--
Josh Berkus
Aglio Database Solutions
San Francisco
