From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bort, Paul" <pbort(at)tmwsystems(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Adding a pgbench run to buildfarm |
Date: | 2006-07-24 08:39:29 |
Message-ID: | 44C48741.3070400@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Kirkwood wrote:
> Tom Lane wrote:
>> "Bort, Paul" <pbort(at)tmwsystems(dot)com> writes:
>>> Andrew said I should solicit opinions as to what parameters to use. A
>>> cursory search through the archives led me to pick a scaling factor of
>>> 10, 5 users, and 100 transactions.
>>
>> 100 transactions seems barely enough to get through startup transients.
>> Maybe 1000 would be good.
>>
>
> Scale factor 10 produces an accounts table of about 130 Mb. Given that
> most HW these days has at least 1G of ram, this probably means not much
> retrieval IO is tested (only checkpoint and wal fsync). Do we want to
> try 100 or even 200? (or recommend scale factor such that size > ram)?
hmm - that "1GB" is a rather optimistic estimate for most of the
buildfarm boxes(mine at least).
Out of the 6 ones I have - only one that actually has much RAM
(allocated) and lionfish for example is rather resource starved at only
48(!) MB of RAM and very limited diskspace - which has been plenty
enough until now doing the builds (with enough swap of course).
I supposed that anything that would result in additional diskspace usage
in excess of maybe 150MB or so would run it out of resources :-(
I'm also not too keen on running excessivly long pgbench runs on some of
the buildfarm members so I would prefer to make that one optional.
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2006-07-24 09:10:53 | Re: UPDATE/DELETE XXX WHERE CURRENT OF cursor_name |
Previous Message | Csaba Nagy | 2006-07-24 08:33:15 | Re: Transaction Speed and real time database |