XFS is a great filesystem and I recommend it to all. However, xfs_fsr
would most likely be unable to defrag an actively used (written to) file
such as a database table.
David Rees wrote:
On Dec 5, 2007 12:53 PM, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
On Wed, Dec 05, 2007 at 12:29:13PM -0800, David Rees wrote:
It would be interesting to find out why PostgreSQL was underperforming
for you. What kind of tuning have you tried? I suspect that the new
async commit options in 8.3 would improve things a lot.
The performance problem was caused by the I/O pattern degrading to
completely random I/O over time. The initial performance or the
performance immediately after a CLUSTER of the tables was easily
as good as the MySQL backend (~20 messages/sec). The steady state
(~6 messages/sec) did not provide sufficient headroom for our
system to allow for clearing out a backlog following any type
of delivery problem. The async commit option in 8.3 will help, but
I expect the HOT updates to be the real win, by allowing the tables
to maintain their cluster order over time. We will report back once
we have some test data.
Thanks, that is one performance concern I have with PostgreSQL
frequently updated/inserted tables/indexes over time, they tend to get
fragmented. I suspect that using XFS along with regular runs of
xfs_fsr would take care of any fragmentation issues, but also agree
that the HOT patches should also help significantly. Looking at the
tables/indexes on one of my systems reveals fairly significant
table/index bloat.
-Dave
!DSPAM:4757195d280511144031109!
