Re: CSStorm occurred again by postgreSQL8.2. (Re: poor - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: CSStorm occurred again by postgreSQL8.2. (Re: poor
Date
Msg-id 44BE0F41.70305@kaltenbrunner.cc
Whole thread Raw
In response to Re: CSStorm occurred again by postgreSQL8.2. (Re: poor performance with Context Switch Storm at TPC-W.)  (Katsuhiko Okano <okano.katsuhiko@oss.ntt.co.jp>)
Responses Re: CSStorm occurred again by postgreSQL8.2. (Re: poor  (Masanori ITOH <ito.masanori@oss.ntt.co.jp>)
List pgsql-hackers
Katsuhiko Okano wrote:
> "Tom Lane <tgl@sss.pgh.pa.us>" wrote:
>> Katsuhiko Okano <okano.katsuhiko@oss.ntt.co.jp> writes:
>>> It does not solve, even if it increases the number of NUM_SUBTRANS_BUFFERS.
>>> The problem was only postponed.
>> Can you provide a reproducible test case for this?
> 
> Seven machines are required in order to perform measurement.
> (DB*1,AP*2,CLient*4)
> Enough work load was not able to be given in two machines.
> (DB*1,{AP+CL}*1)
> 
> 
> It was not able to reappear to a multiplex run of pgbench 
> or a simple SELECT query.
> TPC-W of a work load tool used this time is a full scratch.
> Regrettably it cannot open to the public.
> If there is a work load tool of a free license, I would like to try.


FYI: there is a free tpc-w implementation done by Jan available at:
http://pgfoundry.org/projects/tpc-w-php/


Stefan


pgsql-hackers by date:

Previous
From: Katsuhiko Okano
Date:
Subject: Re: CSStorm occurred again by postgreSQL8.2. (Re: poor performance with Context Switch Storm at TPC-W.)
Next
From: Gregory Stark
Date:
Subject: AUTOCOMMIT currently doesn't handle non-transactional commands very well