Hi, Markus,
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...)
nothing.
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.
Cheers,
Jérôme.
> HTH,
> Markus
--
Jérôme,
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'sioneb@gnireenigne-aigra.rf'.split('@')])"
