From: Pierre C <lists@peufeu.com>
To: Greg Smith <greg@2ndquadrant.com>
To: Scott Carey <scott@richrelevance.com>
Cc: " <david@lang.hm>
Cc: " <david@lang.hm>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: Francisco Reyes <lists@stringsutils.com>
Cc: Pgsql performance <pgsql-performance@postgresql.org>
Subject: Re: 10K vs 15k rpm for analytics
Date: Tue, 09 Mar 2010 14:39:22 +0100
Message-ID: <op.u9ayvwj9eorkce@localhost> (raw)
In-Reply-To: <4B95F222.6040504@2ndquadrant.com>
References: <cone.1267562557.293175.32557.1000@shelca>
<dcc563d11003021312k57e9c558n177e10ad16ab32b1@mail.gmail.com>
<cone.1267565429.453229.32557.1000@shelca>
<dcc563d11003021347h52f94812jf75b5937937a9ed4@mail.gmail.com>
<alpine.DEB.2.00.1003021408340.5131@asgard.lang.hm>
<06A22EB5-2D84-401C-B75F-7CA883695E0A@richrelevance.com>
<4B95F222.6040504@2ndquadrant.com>
On Tue, 09 Mar 2010 08:00:50 +0100, Greg Smith <greg@2ndquadrant.com>
wrote:
> Scott Carey wrote:
>> For high sequential throughput, nothing is as optimized as XFS on Linux
>> yet. It has weaknesses elsewhere however.
>>
When files are extended one page at a time (as postgres does)
fragmentation can be pretty high on some filesystems (ext3, but NTFS is
the absolute worst) if several files (indexes + table) grow
simultaneously. XFS has delayed allocation which really helps.
> I'm curious what you feel those weaknesses are.
Handling lots of small files, especially deleting them, is really slow on
XFS.
Databases don't care about that.
There is also the dark side of delayed allocation : if your application is
broken, it will manifest itself very painfully. Since XFS keeps a lot of
unwritten stuff in the buffers, an app that doesn't fsync correctly can
lose lots of data if you don't have a UPS.
Fortunately, postgres handles fsync like it should be.
A word of advice though : a few years ago, we lost a few terabytes on XFS
(after that, restoring from backup was quite slow !) because a faulty SCSI
cable crashed the server, then crashed it again during xfsrepair. So if
you do xfsrepair on a suspicious system, please image the disks first.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: lists@peufeu.com, greg@2ndquadrant.com, scott@richrelevance.com, david@lang.hm, scott.marlowe@gmail.com, lists@stringsutils.com
Subject: Re: 10K vs 15k rpm for analytics
In-Reply-To: <op.u9ayvwj9eorkce@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox