Обсуждение: postgresql and xfs filesystrem

On Sun, Jan 25, 2009 at 1:47 PM, Ezra Taylor <ezra.taylor@gmail.com> wrote:
> All:
>        Do any of you have gripes about using XFS with the latest version of
> postgres?

I'd not expect there to be much specific benefit to it...

I did some benchmarking, now quite a while ago, which showed XFS to
be, for a totally write-bound workload, a *few* percent better than
ext3/JFS, but note that this is only a minor difference.

The fact that XFS isn't one of the "more highly supported" filesystems
on Linux is something I'd consider a *way* more important factor.

When balancing "oh, maybe a tiny percentage faster" against "oh,
nobody will be in a position to offer much support if anything goes
wrong," I'll take "easier to support" any day.


--
http://linuxfinances.info/info/linuxdistributions.html
Robert Benchley  - "Drawing on my fine command of the English
language, I said nothing."

On 2009-01-25 14:06 -0500, Christopher Browne wrote:
> On Sun, Jan 25, 2009 at 1:47 PM, Ezra Taylor <ezra.taylor@gmail.com> wrote:
>
> > Do any of you have gripes about using XFS with the latest version of
> > postgres?
>
> I'd not expect there to be much specific benefit to it...
>
> I did some benchmarking, now quite a while ago, which showed XFS to
> be, for a totally write-bound workload, a *few* percent better than
> ext3/JFS, but note that this is only a minor difference.
>
> The fact that XFS isn't one of the "more highly supported" filesystems
> on Linux is something I'd consider a *way* more important factor.
>
> When balancing "oh, maybe a tiny percentage faster" against "oh,
> nobody will be in a position to offer much support if anything goes
> wrong," I'll take "easier to support" any day.

In 2007, there was some noise about XFS being much less tolerant
of crashes and loss of power than the other Linux journalling file
systems. Dunno if that was fixed.

--
André Majorel <URL:http://www.teaser.fr/~amajorel/>

On Sonntag 25 Januar 2009 Christopher Browne wrote:
> I did some benchmarking, now quite a while ago, which showed XFS to
> be, for a totally write-bound workload, a *few* percent better than
> ext3/JFS, but note that this is only a minor difference.

Remember that the structure of XFS consists of independent allocation
groups. If your database is big enough to cross several AGs, it might
increase performance by using several CPUs parallel, as an AG is
independent of the others.

> The fact that XFS isn't one of the "more highly supported"
> filesystems on Linux is something I'd consider a *way* more important
> factor.

It looks like a very active project, see:
http://xfs.org/index.php/XFS_Status_Updates
http://oss.sgi.com/projects/xfs/training/index.html

I read a lot about XFS during the last weeks, and tested it. So far, it
was good, and we use it on a test server now with good performance and
reliability (several power outages and kernel crashes happened, no data
loss or anything).

But anyway, I guess the most performance can be gained by optimizing
your postgresql.conf, and increasing memory and using a better RAID with
faster and more 15k SAS disks. The filesystem is not that important for
postgres.

mfg zmi
--
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

On Mon, Jan 26, 2009 at 1:14 AM, Michael Monnerie
<michael.monnerie@is.it-management.at> wrote:

>> I did some benchmarking, now quite a while ago, which showed XFS to
>> be, for a totally write-bound workload, a *few* percent better than
>> ext3/JFS, but note that this is only a minor difference.

XFS is a very active project and, in my opinion, the best filesystem
for UNIX. Apart from a nasty bug back in the second half of 2007 (if I
remember correctly), it's very reliable and fast. I've got more than a
dozen production servers running it since 2002 (aproximattely) and
I've never ever had a problem with it (no data loss, always an
outstanding performance, etc). I also have eight PostgreSQL servers
(8.1 and 8.3 versions) on XFS. As with everything, if you know how to
finetune it (and I would not call myself an expert on it), then you
get a performance boost.

Regarding the benefits of XFS on PostgreSQL, I've come to the
conclusion that, the bigger the database and tables, the better. With
small databases with small tables, the difference in performance...
well, you won't notice it. But try a 30 GB... ;-)

Still, all these "convictions" are very hard to prove. Hard as in
"very much time consuming". I've not run benchmarks in about 4 years,
to be honest, so I would understand you not taking my experience as
"reliable source of information" :-P

--
Jaume Sabater
http://linuxsilo.net/

"Ubi sapientas ibi libertas"

On Mon, Jan 26, 2009 at 5:01 PM, Ezra Taylor <ezra.taylor@gmail.com> wrote:

>                What about XFS performance on databases larger than 1 TB.  We
> are successful running postgres on zfs with x4500 but I'm interested  using
> commodity hardware.

To be honest, I have never worked with databases that big :)

--
Jaume Sabater
http://linuxsilo.net/

"Ubi sapientas ibi libertas"

On Montag 26 Januar 2009 Ezra Taylor wrote:
> What about XFS performance on databases larger than 1 TB.  We
> are successful running postgres on zfs with x4500 but I'm interested
>  using commodity hardware.

See http://en.wikipedia.org/wiki/Xfs#Allocation_groups

XFS was designed for big iron, where "big iron" from that time is
commodity servers of today (4+ cores, 8GB+ RAM, RAID with lots of fast
disks). During mkfs, you can decide how many allocation groups you want,
and by the size of your partition, you decide how big a single AG is.
And if your database spans lots of AGs, high parallelism can take place
if it's well done.

mfg zmi
--
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4