Re: ~400 TPS - good or bad? - Mailing list pgsql-performance

From Greg Smith
Subject Re: ~400 TPS - good or bad?
Date
Msg-id 4C13F225.5020400@2ndquadrant.com
Whole thread Raw
In response to Re: ~400 TPS - good or bad?  (Szymon Kosok <szymon@mwg.pl>)
List pgsql-performance
Szymon Kosok wrote:
> I've found in mailing list archive that scale = 1 is not good idea. So
> we have ran pgbench -s 200 (our database is ~3 GB) -c 10 -t 3000 and
> get about ~600 TPS. Good or bad?
>
pgbench in its default only really tests commit rate, and often that's
not what is actually important to people.  Your results are normal if
you don't have a battery-backed RAID controller.  In that case, your
drives are only capable of committing once per disk rotation, so if you
have 7200RPM drives that's no more than 120 times per second.  On each
physical disk commit, PostgreSQL will include any other pending
transactions that are waiting around too.  So what I suspect you're
seeing is about 100 commits/second, and on average 6 of the 10 clients
have something ready to commit each time.  That's what I normally see
when running pgbench on regular hard drives without a RAID controller,
somewhere around 500 commits/second.

If you change the number of clients to 1 you'll find out what the commit
rate for a single client is, that should help validate whether my
suspicion is correct.  I'd expect a fairly linear increase from 100 to
~600 TPS as your client count goes from 1 to 10, topping out at under
1000 TPS even with much higher client counts.

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us


pgsql-performance by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: ~400 TPS - good or bad?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Analysis Function