[PATCH] pgbench various mods for high volume testing

From: Mark Travis <mtravis15432+pg(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: [PATCH] pgbench various mods for high volume testing
Date: 2013-11-13 06:34:18
Message-ID: CAGsEj6MsXNpFDwMA6MctOh8EEsv6fJNBzX_VZ3LhDfPu22GPOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello. Attached is a patch that I created against REL9_2_4 for
contrib/pgbench. I am willing to re-work the patch for HEAD or another
version if you choose to accept the patch.

The patch supports a number of modifications to pgbench to facilitate
benchmarking using many client processes across many hosts to the
effect of over 100,000 connections sending over 500,000 transactions
per second from over 500 pgbench processes on a dozen client hosts.
This effort was for an open source RDBMS that I have created which
speaks the PostgreSQL Frontend/Backend Protocol. I would like to get
approval to have this patch placed in the main branch for pgbench so
that I don't have to maintain a distinct patch. Even though I created
this patch to test a product which is not PostgreSQL, I hope that you
find the modifications to be useful for PostgreSQL testing, at least
at very high volumes.

That background out of the way, here are the additional features:
----------------------------------
--urandom: use /dev/urandom to provide seed values for randomness.
Without this, multiple pgbench processes are likely to generate the
same sequence of "random" numbers. This was noticeable in InfiniSQL
benchmarking because of the resulting extremely high rate of locked
records from having stored procedures invoked with identical parameter
values.

--per-second=NUM: report per-second throughput rate on stdout. NUM is
the quantity of transactions in each batch that gets counted. The
higher the value, the less frequently gettimeofday gets called.
gettimeofday invocation can become a limiting factor as throughput
increases, so minimizing it is beneficial. For example, with NUM of
100, time will be checked every 100 transactions, which will cause the
per-second output to be in multiples of 100. This enables fine-grained
(per second) analysis of transaction throughput.

-P PASSWORD: pass the db password on the command line. This is
necessary for InfiniSQL benchmarking because hundreds or more separate
pgbench processes can be launched, and InfiniSQL requires password
authentication. Having to manually enter all those passwords would
making benchmarking impossible.

-I: do not abort connection if transaction error is encountered.
InfiniSQL returns an error if records are locked, so pgbench was
patched to tolerate this. This is pending a fix, but until then,
pgbench needs to carry on. The specific error emitted from the server
is written to stderr for each occurrence. The total quantity of
transactions is not incremented if there's an error.
----------------------------

Thank you for your consideration. More background about how I used the
patch is at http://www.infinisql.org
If you find this patch to be useful, then I am willing to modify the
patch as necessary to get it accepted into the code base. I made sure
to create it as a '-c' patch and I haven't snuck in any rogue
whitespace. Apply it in the root of REL9_2_4 as: patch -p1 <
pgbench_persecond-v1.patch

Sincerely,
Mark Travis

Attachment Content-Type Size
pgbench_persecond-v1.patch application/octet-stream 10.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2013-11-13 07:33:45 Re: additional json functionality
Previous Message Haribabu kommi 2013-11-13 06:32:58 Re: Heavily modified big table bloat even in auto vacuum is running