Good morning,
I'd like to ask you some advice on pg tuning in a high
concurrency OLTP-like environment.
The application I'm talking about is running on Pg 8.0.1.
Under average users load, iostat and vmstat show that iowait stays
well under 1%. Tables and indexes scan and seek times are also
Cosimo,
On 8/31/06, Cosimo Streppone [EMAIL PROTECTED] wrote:
The problem is that under peak load, when n. of concurrent transactions
raises, there is a sensible performance degradation.
Could you give us more information about the performance degradation?
Especially cpu load/iostat/vmstat
--On August 31, 2006 5:45:18 PM +0200 Cosimo Streppone
[EMAIL PROTECTED] wrote:
Good morning,
- postgresql.conf, especially:
effective_cache_size (now 5000)
bgwriter_delay (500)
commit_delay/commit_siblings (default)
commit delay and siblings should be turned up, also
On 8/31/06, Cosimo Streppone [EMAIL PROTECTED] wrote:
Good morning,
- postgresql.conf, especially:
effective_cache_size (now 5000)
bgwriter_delay (500)
commit_delay/commit_siblings (default)
while thse settings may help, don't expect too much. ditto shared
buffers. your
On 31-Aug-06, at 11:45 AM, Cosimo Streppone wrote:
Good morning,
I'd like to ask you some advice on pg tuning in a high
concurrency OLTP-like environment.
The application I'm talking about is running on Pg 8.0.1.
Under average users load, iostat and vmstat show that iowait stays
well under
It will be very important to determine if as performance degrades you
are either i/o bound, cpu bound or hindered by some other contention
(db locks, context switching, etc).
Try turning on statement duration logging for all statments or slow
statments (like those over 100ms or some
