Re: good pc but bad performance,why?

From: Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz>
To: huang yaqin <hyq(at)gthome(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: good pc but bad performance,why?
Date: 2004-04-07 11:29:42
Message-ID: 1081337381.522.57.camel@lamb.mcmillan.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 2004-04-07 at 20:56, huang yaqin wrote:
> Hello, Richard Huxton,
>
> You said turning fsync off may cause losing data, that's terrible.
> I use SCSI disk, and file system is ext3. I tune postgresql.conf and can't get any improvement. So what can I do?
> Does SCSI disk and IDE disk have difference?

Yes, turning off fsync means that the database is not guaranteeing
consistency of writes to disk any longer. On the other hand your IDE
system probably never was, because IDE drives just typically turn on
write caching in hardware without telling anyone.

SCSI typically doesn't turn on write caching in the physical drive by
default, as Tom Lane pointed out earlier. Good SCSI has a battery
backed up cache, and then it is OK to turn on write caching, because the
controller has enough battery to complete all writes in the event of a
power failure.

One thing I recommend is to use ext2 (or almost anything but ext3).
There is no real need (or benefit) from having the database on a
journalled filesystem - the journalling is only trying to give similar
sorts of guarantees to what the fsync in PostgreSQL is doing.

The suggestion someone else made regarding use of software raid is
probably also a good one if you are trying to use the on-board RAID at
the moment.

Finally, I would say that because you are seeing poor performance on one
box and great performance on another, you should look at the hardware,
or at the hardware drivers, for the problem - not so much at PostgreSQL.

Of course if it is application performance you want to achieve, we _can_
help here, but you will need to provide more details of what you are
trying to do in your application, including;
- confirmation that you have done a VACUUM and ANALYZE of all tables
before you start
- output from EXPLAIN ANALYZE for slow queries
- anything else you think is useful.

without that sort of detail we can only give vague suggestions, like
"wrap everything in a transaction" - excellent advice, certainly, but
you can read that in the manual.

There are no magic bullets, but I am sure most of the people on this
list have systems that regularly do way more than 50 inserts / second on
server hardware.

Regards,
Andrew McMillan

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201 MOB: +64(21)635-694 OFFICE: +64(4)499-2267
http://survey.net.nz/ - any questions?
-------------------------------------------------------------------------

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Shridhar Daithankar 2004-04-07 11:51:43 Re: good pc but bad performance,why?
Previous Message Steven Butler 2004-04-07 10:39:25 Re: good pc but bad performance,why?