From: | Merlin Moncure <mmoncure(at)gmail(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 13:39:32 |
Message-ID: | AANLkTinHiIdsRDdO1hw94jWbVdoWu6bMR7r72iQKCOkX@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, Jun 12, 2010 at 8:37 AM, Szymon Kosok <szymon(at)mwg(dot)pl> wrote:
> 2010/6/12 Szymon Kosok <szymon(at)mwg(dot)pl>:
>> PS. pgbench scale is set to "1".
>
> 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?
You are being bound by the performance of your disk drives. Since you
have 8gb ram, your database fit in memory once the cache warms up. To
confirm this, try running a 'select only' test with a longer
transaction count:
pgbench -c 10 -t 10000 -S
And compare the results. If you get much higher results (you should),
then we know for sure where the problem is. Your main lines of attack
on fixing disk performance issues are going to be:
*) simply dealing with 400-600tps
*) getting more/faster disk drives
*) doing some speed/safety tradeoffs, for example synchronous_commit
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-06-12 20:46:29 | Re: ~400 TPS - good or bad? |
Previous Message | Szymon Kosok | 2010-06-12 12:37:21 | Re: ~400 TPS - good or bad? |