From: | eric soroos <eric-psql(at)soroos(dot)net> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Low Budget Performance, Part 2 |
Date: | 2002-11-27 20:45:39 |
Message-ID: | 26289626.1173721357@[4.42.179.151] |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, 27 Nov 2002 14:19:22 -0500 in message <21018(dot)1038424762(at)sss(dot)pgh(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> eric soroos <eric-psql(at)soroos(dot)net> writes:
> > Running pgbench with: scaling factor=1, # transactions = 100, and
> > #clients =1,2,3,5,10,15
>
> The scaling factor has to at least equal the max # of clients you intend
> to test, else pgbench will spend most of its time fighting update
> contention (parallel transactions wanting to update the same row).
>
Ok, with the scaling factor set at 20, the new results are more in line with expectations:
For 1-10 clients, IDE gets 25-30 tps, SCSI 40-50 (more with more clients, roughly linear).
The CPU was hardly working in these runs (~50% on scsi, ~20% on ide), vs nearly 100% on the previous run.
I'm suspect that the previous runs were colored by having the entire dataset in memory as well as the update contention.
eric
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2002-11-28 09:31:39 | Re: Low Budget Performance, Part 2 |
Previous Message | Tom Lane | 2002-11-27 19:19:22 | Re: Low Budget Performance, Part 2 |