Le mardi 19 septembre 2006 à 15:09 +0200, Markus Schaber a écrit :
> Hi, Jerome,
> Jérôme BENOIS wrote:
> >>> Now i Have 335 concurrent connections, i decreased work_mem parameter to
> >>> 32768 and disabled Hyper Threading in BIOS. But my CPU load is still
> >>> very important.
> >> What are your settings for commit_siblings and commit_delay?
> > It default :
> > #commit_delay = 01 # range 0-100000, inmicroseconds
> > #commit_siblings = 5 # range 1-1000
> You should uncomment them, and play with different settings. I'd try a
> commit_delay of 100, and commit_siblings of 5 to start with.
> > I plan to return to previous version : 7.4.6 in and i will reinstall all
> > in a dedicated server in order to reproduce and solve the problem.
> You should use at least 7.4.13 as it fixes some critical buts that were
> in 7.4.6. They use the same on-disk format and query planner logic, so
> they should not have any difference.
> I don't have much more ideas what the problem could be.
> Can you try to do some profiling (e. G. with statement logging) to see
> what specific statements are the one that cause high cpu load?
> Are there other differences (besides the PostgreSQL version) between the
> two installations? (Kernel, libraries, other software...)
I returned to the previous version 7.4.6 in my production server, it's
work fine !
And I plan to reproduce this problem in a dedicated server, and i will
send all informations in this list in the next week.
I hope your help for solve this problem.
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'sioneb(at)gnireenigne-aigra(dot)rf'.split('@')])"
In response to
pgsql-performance by date
|Next:||From: Hannes Dorbath||Date: 2006-09-22 08:32:02|
|Subject: Opteron vs. Xeon "benchmark"|
|Previous:||From: Luke Lonergan||Date: 2006-09-22 03:46:41|
|Subject: Re: Large tables (was: RAID 0 not as fast as|