Re: good pc but bad performance,why? - Mailing list pgsql-performance

From Aaron Werman
Subject Re: good pc but bad performance,why?
Date
Msg-id LAW10-OE60bddQzCjEC00019080@hotmail.com
Whole thread Raw
In response to Re: good pc but bad performance,why?  (huang yaqin <hyq@gthome.com>)
List pgsql-performance
fsync I'm thinking 50 inserts, if autocommiting is 50TPS = ~100 IO per
second (50 WAL + checkpoint IO) = roughly the I/O rate of a single drive.

Huang - Are you using a single drive for pg? If so, there is a safety
problem of both the data and logs used for recovery on the same drive. If
the drive crashes, there is nothing left for recovery.

Also, there is a big contention issue, since the log is a fast sequential
write, and checkpointing is random. If the log is on a separate drive,
you'll probably see insert speed at disk sequential write speed, since the
other drive(s) should hopefully be able to keep up when checkpointing. If
they share the same drive, you'll see an initial burst of inserts, then a
order of magnitude performance drop-off as soon as you checkpoint - because
the disk is interleaving the log and data writes.

fsync off is only appropriate for externally recoverable processes, such as
loading an empty server from a file.

/Aaron

----- Original Message -----
From: "Richard Huxton" <dev@archonet.com>
To: "huang yaqin" <hyq@gthome.com>; "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-performance@postgresql.org>
Sent: Wednesday, April 07, 2004 4:33 AM
Subject: Re: [PERFORM] good pc but bad performance,why?


On Wednesday 07 April 2004 05:00, huang yaqin wrote:
> hello!
>
> Thanks, you are right.
> I use "postmaster -o "-F" " to start my PG,and performance improved
> greatly.

I don't think Tom was recommending turning fsync off. If you have a system
crash/power glitch then the database can become corrupted.

If you are happy the possibility if losing your data, write performance will
improve noticably.

--
  Richard Huxton
  Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: plan problem
Next
From: Josh Berkus
Date:
Subject: Re: [ADMIN] Raw devices vs. Filesystems