From: Yann Dupont <Yann.Dupont@univ-nantes.fr>
To: xfs@oss.sgi.com
Subject: Re: Bad performance with XFS + 2.6.38 / 2.6.39
Date: Wed, 21 Dec 2011 10:08:52 +0100 [thread overview]
Message-ID: <4EF1A224.2070508@univ-nantes.fr> (raw)
In-Reply-To: <CACaf2ab-YjXAFm767MmRU5iuOmvkqQW3ZTfQewD5SGvF-opgYQ@mail.gmail.com>
Le 12/12/2011 03:00, Xupeng Yun a écrit :
>
>
> On Mon, Dec 12, 2011 at 09:00, Dave Chinner <david@fromorbit.com
> <mailto:david@fromorbit.com>> wrote:
>
> Oh, of course, now I remember what the problem is - it's a locking
> issue that was fixed in 3.0.11, 3.1.5 and 3.2-rc1.
>
>
> Got it, thanks.
>
> --
> Xupeng Yun
> http://about.me/xupeng
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
I'm seeing more or less the same here.
Generally speaking XFS code in recent kernels seems to decrease CPU
usage and be faster, which is a very good thing (good works, guy). But...
On two particular server, with recent kernels, I experience a much
higher load than expected, but it's very hard to tell what's wrong. The
system seems more in I/O wait. Older kernels (2.6.32.xx and 2.6.26.xx)
gives better results.
Following this thread, I thought I have the same problems, but it's
probably not the case, as I have tested 2.6.38.xx, 3.0.13, 3.1.5 with
same results.
Thoses servers are mail (dovecot) servers, with lots of simultaneous
imap clients (5000+) an lots of simultaneous message delivery.
These are linux-vservers, on top of LVM volumes. The storage is SAN with
15k RPM SAS drives (and battery backup).
I know barriers were disabled in older kernels, so with recents kernels,
XFS volumes were mounted with nobarrier.
As those servers are critical for us, I can't really test, hardly give
you more precise numbers, and I don't know how to accurately reproduce
this platform to test what's wrong. I know this is NOT a precise bug
report and it won't help much.
All I can say IS :
- read operations seems no slower with recent kernels, backups take
approximatively the same time ;
- I'd say (but I have no proof) that delivery of new mails takes more
time and is more synchronous than before, like nobarrier have no effect.
Does this ring a bell to some of you ?
Thanks,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-12-21 9:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-11 12:45 Bad performance with XFS + 2.6.38 / 2.6.39 Xupeng Yun
2011-12-11 23:39 ` Dave Chinner
2011-12-12 0:40 ` Xupeng Yun
2011-12-12 1:00 ` Dave Chinner
2011-12-12 2:00 ` Xupeng Yun
2011-12-12 13:57 ` Christoph Hellwig
2011-12-21 9:08 ` Yann Dupont [this message]
2011-12-21 15:10 ` Stan Hoeppner
2011-12-21 17:56 ` Yann Dupont
2011-12-21 22:26 ` Dave Chinner
2011-12-22 9:23 ` Yann Dupont
2011-12-22 11:02 ` Yann Dupont
2012-01-02 10:06 ` Yann Dupont
2012-01-02 16:08 ` Peter Grandi
2012-01-02 18:02 ` Peter Grandi
2012-01-04 10:54 ` Yann Dupont
2012-01-02 20:35 ` Dave Chinner
2012-01-03 8:20 ` Yann Dupont
2012-01-04 12:33 ` Christoph Hellwig
2012-01-04 13:06 ` Yann Dupont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EF1A224.2070508@univ-nantes.fr \
--to=yann.dupont@univ-nantes.fr \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox