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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to