Date: Tue, 12 Jan 2010 00:53:29 +0100
To: "Bob Dusek" <redusek@gmail.com>, "Ivan Voras" <ivoras@freebsd.org>
Subject: Re: performance config help
From: =?utf-8?Q?Pierre_Fr=C3=A9d=C3=A9ric_Caillau?= =?utf-8?Q?d?=
	<lists@peufeu.com>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
MIME-Version: 1.0
References: <61039b861001110544o2c352763q13dcf9d78a156714@mail.gmail.com>
	<dcc563d11001110550s2af6d559l5db495d5e0fc6a57@mail.gmail.com>
	<61039b861001110842g15bb1f26jc50b6e6762e01427@mail.gmail.com>
	<hifm6q$dp8$1@ger.gmane.org>
	<61039b861001111057t6443b526pdc312ff2717d6227@mail.gmail.com>
Content-Transfer-Encoding: 7bit
Message-ID: <op.u6d7bfnucke6l8@soyouz>
In-Reply-To: <61039b861001111057t6443b526pdc312ff2717d6227@mail.gmail.com>
User-Agent: Opera Mail/9.62 (Linux)


> Each of the 256 requests was being processed by a php process.  So, it  
> could
> certainly be faster.  But, the fact that we're seeing the db performance
> degrade would seem to indicate that our application is fast enough to  
> punish
> the db.  Isn't that true?

	Not necessarily. Your DB still has lots of idle CPU, so perhaps it's your  
client which is getting over the top. Or you have locking problems in your  
DB.
	Things to test :

	- vmstat on the benchmark client
	- iptraf on the network link
	- monitor ping times between client and server during load test

	Some time ago, I made a benchmark simulating a forum. Postgres was  
saturating the gigabit ethernet between server and client...

	If those PHP processes run inside Apache, I'd suggest switching to  
lighttpd/fastcgi, which has higher performance, and uses a limited,  
controllable set of PHP processes (and therefore DB connections), which in  
turn uses much less memory.

	PS : try those settings :

fsync = fdatasync
wal_buffers = 64MB
walwriter_delay = 2ms
synchronous commits @ 1 s delay