Re: High context switches occurring

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Anjan Dave" <adave(at)vantage(dot)com>
Cc: "Vivek Khera" <vivek(at)khera(dot)org>, "Postgresql Performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: High context switches occurring
Date: 2005-12-06 23:45:03
Message-ID: 22673.1133912703@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Anjan Dave" <adave(at)vantage(dot)com> writes:
> -bash-3.00$ time pgbench -c 1000 -t 30 pgbench
> starting vacuum...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> number of clients: 1000
> number of transactions per client: 30
> number of transactions actually processed: 30000/30000
> tps = 45.871234 (including connections establishing)
> tps = 46.092629 (excluding connections establishing)

I can hardly think of a worse way to run pgbench :-(. These numbers are
about meaningless, for two reasons:

1. You don't want number of clients (-c) much higher than scaling factor
(-s in the initialization step). The number of rows in the "branches"
table will equal -s, and since every transaction updates one
randomly-chosen "branches" row, you will be measuring mostly row-update
contention overhead if there's more concurrent transactions than there
are rows. In the case -s 1, which is what you've got here, there is no
actual concurrency at all --- all the transactions stack up on the
single branches row.

2. Running a small number of transactions per client means that
startup/shutdown transients overwhelm the steady-state data. You should
probably run at least a thousand transactions per client if you want
repeatable numbers.

Try something like "-s 10 -c 10 -t 3000" to get numbers reflecting test
conditions more like what the TPC council had in mind when they designed
this benchmark. I tend to repeat such a test 3 times to see if the
numbers are repeatable, and quote the middle TPS number as long as
they're not too far apart.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Stone 2005-12-07 00:23:07 Re: postgresql performance tuning
Previous Message Ameet Kini 2005-12-06 22:03:22 Re: postgresql performance tuning