Greg Copeland wrote:
> > The paper does recommend ext3, but the differences between file systems
> > are very small. If you are seeing 'cp' as slow, I wonder if it may be
> > something more general, like poorly tuned hardware or something. You can
> > use 'dd' to throw some data around the file system and see if that is
> > showing slowness; compare those numbers to another machine that has
> > different hardware/OS.
> >
> > Also, though ext3 is slower, turning fsync off should make ext3 function
> > similar to ext2. That would be an interesting test if you suspect ext3.
>
> I'm curious as to why you recommended ext3 versus some other (JFS,
> XFS). Do you have tests which validate that recommendation or was it a
> simple matter of getting the warm fuzzies from familiarity?
I used the attached email as a reference. I just changed the wording to
be:
File system choice is particularly difficult on Linux because there are
so many file system choices, and none of them are optimal: ext2 is not
entirely crash-safe, ext3 and xfs are journal-based, and Reiser is
optimized for small files. Fortunately, the journaling file systems
aren't significantly slower than ext2 so they are probably the best
choice.
so I don't specifically recommend ext3 anymore. As I remember, ext3 is
good only in that it can read ext2 file systems. I think XFS may be the
best bet.
Can anyone clarify if "data=writeback" is safe for PostgreSQL.
Specifically, are the data files recovered properly or is this option
only for a filesystem containing WAL?
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
>From [EMAIL PROTECTED] Sun Apr 14
>10:26:49 2002
Return-path: <[EMAIL PROTECTED]>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g3EEQmS21621
for <[EMAIL PROTECTED]>; Sun, 14 Apr 2002 10:26:48 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP id 94C5B475C9B
for <[EMAIL PROTECTED]>; Sun, 14 Apr 2002 10:26:43 -0400 (EDT)
Received: from sphinx.mythic-beasts.com (sphinx.mythic-beasts.com [195.82.107.246])
by postgresql.org (Postfix) with ESMTP id 1E27547517F
for <[EMAIL PROTECTED]>; Sun, 14 Apr 2002 10:25:31 -0400 (EDT)
Received: from matthew (helo=localhost)
by sphinx.mythic-beasts.com with local-esmtp (Exim 3.33 #2)
id 16wkwR-0000p2-00; Sun, 14 Apr 2002 15:25:19 +0100
Date: Sun, 14 Apr 2002 15:25:19 +0100 (BST)
From: Matthew Kirkwood <[EMAIL PROTECTED]>
X-X-Sender: <[EMAIL PROTECTED]>
To: "Riebs, Andy" <[EMAIL PROTECTED]>
cc: <[EMAIL PROTECTED]>
Subject: Re: [GENERAL] Performance Tuning Document?
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
Sender: [EMAIL PROTECTED]
Status: OR
On Thu, 28 Mar 2002, Matthew Kirkwood wrote:
[ oops, forgot to send this ages ago ]
> > > Under the "crossSectionTests(Mixed IR)" part of an OSDB run, a
> > > large number of shared_buffers causes severe slowdown on one of
> > > the tests -- it goes from a little over 200 seconds to nearly
> > > 2000.
> > --postgresql=no_hash_index
> Ah, that would make a lot of sense. I'll do a run again with
> that option and see what turns up.
That was right on the nose. The numbers are much better now.
My initial interest was in benchmarking different filesystems
on Linux. In case anyone is interested, here are today's
numbers:
tuning? single ir cs-ir oltp cs-oltp
(sec) (tps) (sec) (tps) (sec)
ext3 kn 841.28 61.52 203.33 407.58 159.72
ext3-wb kn 841.19 63.73 217.19 406.30 160.88
ext3-jd kn 839.96 58.96 203.02 307.85 159.89
jfs kn 840.53 62.74 205.90 348.33 177.70
minix kn 841.51 62.12 201.44 343.87 176.68
ext2 kn 840.72 65.02 205.40 338.20 182.22
ext3-wb is ext3 with the "data=writeback" mount option. ext3-jd
is ext3 with "data=journal" and a 200Mb journal instead of the
usual 32Mb one. All filesystems were mounted noatime.
postgresql.conf for all these runs looks like:
tcpip_socket = true
shared_buffers = 10240
max_fsm_relations = 100
max_fsm_pages = 10000
max_locks_per_transaction = 256
wal_buffers = 10240
sort_mem = 5120000
vacuum_mem = 81920
Without hash indexes, it looks like only OLTP loads can
differentiate the filesystems. Sometime (once I have got
a more recent kernel going) I'll try a dataset larger than
memory.
Matthew.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
