Re: ~400 TPS - good or bad?

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Szymon Kosok <szymon(at)mwg(dot)pl>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: ~400 TPS - good or bad?
Date: 2010-06-12 20:46:29
Message-ID: 4C13F225.5020400@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndQuadrant(dot)com www.2ndQuadrant.us

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2010-06-13 01:08:17 Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?
Previous Message Merlin Moncure 2010-06-12 13:39:32 Re: ~400 TPS - good or bad?