Forum .LRN Q&A: Tuning

Collapse
Posted by Steve Manning on
Hi All,

I spent a couple of hours (very) early this morning laying siege (http://www.joedog.org/JoeDog/Siege) to one of our customers production servers to get a better feel for its performance limits. The machine in question is a Dual Xeon 3.2Ghz 64bit (although running 32bit currently) with 4Gb RAM and 72Gb SATA RAID drives.

The results appear to be that it max's out at around 23,000 requests/5 min of testing - about 4,600/min. Looking at the Analog results it appears to be approaching these levels and its peaking at about 80% at the moment so I'm looking for suggestions on tuning the box:

1. Maxconnections is 160 (up from 80) and Threads is 40 (up from a conservative 20). Would increasing these any further be detrimental or is that an unknown (suck it and see)?

2. I notice the default config for 5.1 which it uses does not include any caching for ADP's or FastPath as per this page http://panoptic.com/wiki/aolserver/AOLserver_Tuning%2C_Troubleshooting_and_Scaling

I realise that its a bit old but I'm wondering if there is a reason why I can't use them. Given that we are serving around 80 - 100 requests/page I think that cache of static files such as images would help.

3. Is there a definitive document for Postgres tuning for OACS. There are plenty of documents available on PG tuning but they often seem to contradict each other.

Any thoughts and suggestions would be appreciated.

TIA

- Steve

Collapse
3: Re: Tuning (response to 1)
Posted by Dave Bauer on
Steve,

Well, what is loaded on the server? Is it bound by the limits of the CPU, I/O, or memory? If its CPU or memory, what's using up the memory or CPU, AOLserver or PostgreSQL?

Collapse
2: Re: Tuning (response to 1)
Posted by Patrick Giagnocavo on
Hmmm...

First, run top or some other program and try to figure out if either the AOLserver or Postgres process is CPU-bound.

Most likely (if you are CPU-bound) AOLserver will be the first to use up almost all CPU on the system - it won't use 100% because some of the time it will be waiting for info from Postgres.

Second, check Postgres tunables like max_fsm_relations, vacuum_mem and sort_mem, in addition to setting the shared buffers to be higher.

Third, if you really need performance turn off the fsync, which causes Postgres to flush the disk buffers after every transaction. I have done this on Solaris, which writes a transaction log for disk integrity anyways, with no problems. There is however the possibility of data loss should someone yank power to the system while in the middle of a transaction.

Collapse
4: Re: Tuning (response to 1)
Posted by Steve Manning on
Oops Muppet! I posted in the .Lrn Q&A rather than Q&A - sorry about that, I'll send it across.

Soz.