public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jens Rosenboom <j.rosenboom@syseleven.de>
Cc: xfs@oss.sgi.com
Subject: Re: Performance problem with multiple parallel rm -rf's
Date: Thu, 3 Dec 2009 12:05:26 +1100	[thread overview]
Message-ID: <20091203010526.GR30608@discord.disaster> (raw)
In-Reply-To: <4B163B20.6030808@syseleven.de>

On Wed, Dec 02, 2009 at 11:02:08AM +0100, Jens Rosenboom wrote:
> On a large 13TB XFS volume that is being used for backups, I am seeing  
> bad performance if multiple "rm -rf" processes are running in parallel.  
> The backups are being done with rsnapshot and the first operation it  
> does is removing the oldest snapshot. A single rsnapshot does this in  
> reasonable time, but if four jobs are started at the same time, all  
> their rm processes run for hours without making much progress.
>
> This seems to be related to the planned optimizations in
>
> http://xfs.org/index.php/Improving_Metadata_Performance_By_Reducing_Journal_Overhead

Not directly, I think. More likely is the effect of cold caches
on the inode read rate.

That is, if you are running cold-cache 'rm -rf' operations, there is
a substantial amount of *read* IO executed to pull the inodes into
memory before they are unlinked. (i.e. an unlink is roughly
1 read IO and two write IOs).

If you are doing multiple cold-cache 'rm -rf' in parallel, you
will be causing more disk seeks for reading the inodes you are
trying to unlink, and as such this will slow down the unlink rate
as the unlink can only go as fast as the inodes can be read off
disk.

Effectively there is not much you can do about this - you could try
doing a traversal of the old snapshot first (e.g
ls -lR <snapshot> > /dev/null) to get the cache populated as fast as
possible before doing the unlink traversal, but that requires you
have plenty of memory available (i.e. to hold more inodes than
multiple parallel snapshot traversals will read).

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

      parent reply	other threads:[~2009-12-03  1:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-02 10:02 Performance problem with multiple parallel rm -rf's Jens Rosenboom
2009-12-02 11:41 ` Sujit K M
2009-12-02 14:49 ` Justin Piszcz
2009-12-03  1:05 ` Dave Chinner [this message]

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=20091203010526.GR30608@discord.disaster \
    --to=david@fromorbit.com \
    --cc=j.rosenboom@syseleven.de \
    --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