public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: David Fuller <dfuller@epoch.com>
Cc: xfs@oss.sgi.com
Subject: Re: Fragmentation Issue We Are Having
Date: Wed, 11 Apr 2012 23:24:53 -0500	[thread overview]
Message-ID: <4F865915.80104@sandeen.net> (raw)
In-Reply-To: <CADrkzim1B9fU5sK73uGicPpr7D+ANPwKWGdMS7TroyoX5ncdOw@mail.gmail.com>

On 4/11/12 9:55 PM, David Fuller wrote:
> Dave,
> 
> Thanks so much for that informative read.  This helps me fight my case that systematic
> defrags are not needed and are bad for the system in general.
> 
> After reading this I did do some checks against some of our larger tables and found that
> on average we are storing about 2.5GB per extent. For me that seems pretty reasonable
> to me and does not require defrag'ing at this time.

I've also added a visual aid to that faq entry to show how quickly the frag factor
approaches 100% :)

-Eric

> --David Fuller
> 
> 
> <http://www.topshelfads.com/email/sig/epochbestbilling.jpg>
> 
> 
> On Wed, Apr 11, 2012 at 7:16 PM, Dave Chinner <david@fromorbit.com <mailto:david@fromorbit.com>> wrote:
> 
>     On Wed, Apr 11, 2012 at 06:04:25PM -0700, David Fuller wrote:
>     > We seen to be having an issue whereby our database server
>     > gets to 90% or higher fragmentation.  When it gets to this point
>     > we would need to remove form production and defrag using the
>     > xfs_fsr tool.
> 
>     Bad assumption.
> 
>     > The server does get a lot of writes and reads.  Is
>     > there something we can do to reduce the fragmentation or could
>     > this be a result of hard disk tweaks we use or mount options?
>     >
>     > here is some fo the tweaks we do:
>     >
>     > /bin/echo "512" > /sys/block/sda/queue/read_ahead_kb
>     > /bin/echo "10000" > /sys/block/sda/queue/nr_requests
>     > /bin/echo "512" > /sys/block/sdb/queue/read_ahead_kb
>     > /bin/echo "10000" > /sys/block/sdb/queue/nr_requests
>     > /bin/echo "noop" > /sys/block/sda/queue/scheduler
>     > /bin/echo "noop" > /sys/block/sdb/queue/scheduler
> 
>     They have no effect on filesystem fragmentation.
> 
>     > Adn here are the mount options on one of our servers:
>     >
>     >  xfs     rw,noikeep,allocsize=256M,logbufs=8,sunit=128,swidth=2304
>     >
>     > the sunit and swidth vary on each server based on disk drives.
>     >
>     > We do use LVM on the volume where the mysql data is stored
>     > as we need this for snapshotting.  Here is an example of a current state:
>     >
>     > xfs_db -c frag -r /dev/mapper/vgmysql-lvmysql
>     > actual 42586, ideal 3134, fragmentation factor 92.64%
> 
>     Read this first:
> 
>     http://xfs.org/index.php/XFS_FAQ#Q:_The_xfs_db_.22frag.22_command_says_I.27m_over_50.25.__Is_that_bad.3F
> 
>     Then decide whether 10 extents per file is really a problem or not.
> 
>     Cheers,
> 
>     Dave.
>     --
>     Dave Chinner
>     david@fromorbit.com <mailto:david@fromorbit.com>
> 
> 
> 
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

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

  reply	other threads:[~2012-04-12  4:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-12  1:04 Fragmentation Issue We Are Having David Fuller
2012-04-12  2:16 ` Dave Chinner
2012-04-12  2:55   ` David Fuller
2012-04-12  4:24     ` Eric Sandeen [this message]
2012-04-12  7:57 ` Brian Candler
2012-04-13  0:09   ` David Fuller
2012-04-13  7:19     ` Brian Candler
2012-04-13  7:56       ` Dave Chinner
2012-04-13  8:17         ` Brian Candler
2012-04-17  0:26           ` Dave Chinner
2012-04-17  8:58             ` Brian Candler
2012-04-18  1:36               ` Dave Chinner
2012-04-18  9:00                 ` Brian Candler
2012-04-19 23:12                   ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2012-04-19 19:54 Richard Scobie

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=4F865915.80104@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=dfuller@epoch.com \
    --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