On 06/13/2011 08:27 PM, Jeff Janes wrote:
pgbench sends each query (per connection) and waits for the reply
before sending another.
Do we know whether sysbench does that, or if it just stuffs the
kernel's IPC buffer full of queries without synchronously waiting for
individual replies?
sysbench creates a thread for each client and lets them go at things at
whatever speed they can handle. You have to setup pgbench with a worker
per core to get them even close to level footing. And even in that
case, sysbench has a significant advantage, because it's got the
commands it runs more or less hard-coded in the program. pgbench is
constantly parsing things in its internal command language and then
turning them into SQL requests. That's flexible and allows it to be
used for some neat custom things, but it uses a lot more resources to
drive the same number of clients.
I can't get sysbench to "make" for me, or I'd strace in single client
mode and see what kind of messages are going back and forth.
If you're using a sysbench tarball, no surprise. It doesn't build on
lots of platforms now. If you grab
http://projects.2ndquadrant.it/sites/default/files/bottom-up-benchmarking.pdf
it has my sysbench notes starting on page 34. I had to checkout the
latest version from their development repo to get it to compile on any
recent system. The attached wrapper script may be helpful to you as
well to help get over the learning curve for how to run the program; it
iterates sysbench over a number of database sizes and thread counts
running the complicated to setup OLTP test.
--
Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
#!/bin/bash
SB="$HOME/0.4/sysbench/sysbench"
DB="--pgsql-user=postgres --pgsql-password=password --pgsql-db=sysbench
--pgsql-host=localhost --db-driver=pgsql"
#DB="--mysql-user=root --db-driver=mysql --mysql-table-engine=innodb
--mysql-db=sysbench"
#THREADS="1 2 3 4 5 6 7 8 9 10 11 12 16 24 32 48 64 96"
THREADS="1"
TIME=10
TEST_PARAM="--oltp-read-only=off --oltp-test-mode=complex"
#TEST_PARAM="--oltp-read-only=on --oltp-test-mode=simple"
SIZES="10000"
#SIZES="10000 100000 1000000 10000000 50000000 100000000 500000000 1000000000"
# In complex, non read-only mode, there will be duplicate key issues, and
# threads will fail with deadlock--causing no value to be returned.
#TEST_PARAM="--oltp-test-mode=complex"
for s in $SIZES
do
SIZE_PARAM="--oltp-table-size=$s"
# Just in case!
$SB $DB --test=oltp cleanup
$SB $DB $SIZE_PARAM --test=oltp prepare
for t in $THREADS
do
echo -n $t threads:
$SB $DB --test=oltp $TEST_PARAM $SIZE_PARAM --init-rng --max-requests=0
--max-time=$TIME --num-threads=$t run 2>&1 # | grep "read/write requests"
done
$SB $DB --test=oltp cleanup
done
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
