Re: Adding a pgbench run to buildfarm

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

In response to

Browse pgsql-hackers by date

  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