Greg Smith wrote:
Try something more in the range of 4 clients/CPU and set the scale to
closer to twice that (so with a dual-core system you might do 8 clients
and a scale of 16). If you really want to simulate a large number of
clients, do that on another system and connect to the server remo
Guillaume Smet wrote:
Also with SATA? If your SATA disk is lying about effectively SYNCing
the data, I'm not that surprised you don't see any improvement. Being
slower is a bit surprising though.
The disc is not lying, but LVM does not support write barriers, so the
result is the same. Indeed
* Guillaume Smet:
> On Jan 22, 2008 9:32 AM, Florian Weimer <[EMAIL PROTECTED]> wrote:
>> > Maybe it's just my test box.. single SATA-II drive, XFS on top of LVM.
>>
>> Ours was ext3, no LVM or RAID.
>
> Also with SATA?
Yes, desktop-class SATA.
> If your SATA disk is lying about effectively SYNC
On Jan 22, 2008 9:32 AM, Florian Weimer <[EMAIL PROTECTED]> wrote:
> > Maybe it's just my test box.. single SATA-II drive, XFS on top of LVM.
>
> Ours was ext3, no LVM or RAID.
Also with SATA? If your SATA disk is lying about effectively SYNCing
the data, I'm not that surprised you don't see any i
* Hannes Dorbath:
> I might completely misunderstand this feature. Shouldn't
> "synchronous_commit = off" improve performance?
Indeed.
We've seen something similar in one test, but couldn't reproduce it in
a clean environment so far.
> Maybe it's just my test box.. single SATA-II drive, XFS on
Em Mon, 21 Jan 2008 15:45:54 -0800
Jeff Davis <[EMAIL PROTECTED]> escreveu:
> On Mon, 2008-01-21 at 18:31 -0500, Greg Smith wrote:
> > pgbench doesn't handle 100 clients at once very well on the same
> > box as the server, unless you have a pretty serious system. The
> > pgbench program itself ha
On Mon, 21 Jan 2008, Jeff Davis wrote:
He was referring to the CFQ I/O scheduler. I don't think that will
affect pgbench itself, because it doesn't read/write to disk, right?
It does if you are writing latency log files but it shouldn't be in the
cases given. But there's something weird abou
On Mon, 2008-01-21 at 18:31 -0500, Greg Smith wrote:
> pgbench doesn't handle 100 clients at once very well on the same box as
> the server, unless you have a pretty serious system. The pgbench program
> itself has a single process model that doesn't handle the CFQ round-robin
> very well at al
On Mon, 21 Jan 2008, Hannes Dorbath wrote:
pgbench -i -s 10 -U pgsql -d bench && pgbench -t 1000 -c 100 -U pgsql -d
bench
pgbench doesn't handle 100 clients at once very well on the same box as
the server, unless you have a pretty serious system. The pgbench program
itself has a single proc
On Mon, 2008-01-21 at 22:55 +0100, Hannes Dorbath wrote:
> I might completely misunderstand this feature. Shouldn't
> "synchronous_commit = off" improve performance?
>
> Whatever I do, I find "synchronous_commit = off" to degrade performance.
>
> Especially it doesn't like the CFQ I/O scheduler
Hello
synchronous_commit = off is well for specific load,
try only one connect pgbench ~ it is analogy for database import or
some administrator's work.
Regards
Pavel Stehule
On 21/01/2008, Hannes Dorbath <[EMAIL PROTECTED]> wrote:
> I might completely misunderstand this feature. Shouldn't
> "
I might completely misunderstand this feature. Shouldn't
"synchronous_commit = off" improve performance?
Whatever I do, I find "synchronous_commit = off" to degrade performance.
Especially it doesn't like the CFQ I/O scheduler, it's not so bad with
deadline. Synthetic load like
pgbench -i -
12 matches
Mail list logo
