public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Yann Dupont <Yann.Dupont@univ-nantes.fr>
Cc: xfs@oss.sgi.com
Subject: Re: Bad performance with XFS + 2.6.38 / 2.6.39
Date: Wed, 21 Dec 2011 09:10:21 -0600	[thread overview]
Message-ID: <4EF1F6DD.8020603@hardwarefreak.com> (raw)
In-Reply-To: <4EF1A224.2070508@univ-nantes.fr>

On 12/21/2011 3:08 AM, Yann Dupont wrote:
> 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 ?

1.  What mailbox format are you using?  Is this a constant or variable?
2.  Is the Dovecot rev and config the same everywhere, before/after?
3.  Are Dovecot instances using NFS to access the XFS volumes?
4.  Is this a  Dovecot 2.x cluster with director and NFS storage?

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-12-21 15:10 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
2011-12-21 15:10           ` Stan Hoeppner [this message]
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=4EF1F6DD.8020603@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=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