Re: Major Performance decrease after some hours

From: "Peter Bauer" <peter(dot)m(dot)bauer(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Major Performance decrease after some hours
Date: 2006-10-10 05:49:46
Message-ID: 764c9e910610092249v19b30ae3r7541ad0137c74f5a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi all,

2006/10/5, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Peter Bauer" <peter(dot)m(dot)bauer(at)gmail(dot)com> writes:
> > tps = 50.703609 (including connections establishing)
> > tps = 50.709265 (excluding connections establishing)
>
> That's about what you ought to expect for a single transaction stream
> running on honest disk hardware (ie, disks that don't lie about write
> complete). You can't commit a transaction more often than once per disk
> revolution, because you have to wait for the current WAL file endpoint
> to pass under the heads again. If there are multiple clients then
> "ganging" concurrent commits is possible, but you tested only one.
>
> The benchmark you reference might have been done on disks with battery
> backed write cache. Or it might have been just plain unsafe (ie, the
> equivalent of fsync off, but in hardware :-()

You are right, i performed the pgbench tests on another machine with
the same hardware but a kernel which supports the onboard Dell Raid
Controller with battery backed write cache and the result is about 400
tps. We will see how much difference this makes in practice but at
least i know where the "problem" was.

thx,
Peter

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2006-10-10 05:52:58 Re: performace review
Previous Message Neil Conway 2006-10-10 04:30:30 Re: query optimization with UDFs