[Top] [All Lists]

Re: Performance problems with millions of inodes

To: xfs@xxxxxxxxxxx
Subject: Re: Performance problems with millions of inodes
From: Christoph Litauer <litauer@xxxxxxxxxxxxxx>
Date: Wed, 25 Jun 2008 16:46:30 +0200
In-reply-to: <4862598B.80905@xxxxxxxxxxxxxx>
References: <4862598B.80905@xxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Macintosh/20080421)
Christoph Litauer schrieb:

sorry if this has been asked before, I am new to this mailing list. I
didn't find any hints in the FAQ or by googling ...

I have a backup server driving two kinds of backup software: bacula and
backuppc. bacula saves it's backups on raid1, backuppc on raid2
(different hardware, but both fast hardware raids).
I have massive performance problems with backuppc which I tracked down
to performance problems of the filesystem on raid2 (I think so). The
main difference between the two backup systems is that backuppc uses
millions of inodes for it's backup (in fact it duplicates the directory
structure of the backup client).

raid1 consists of 91675 inodes, raid2 of 143646439. The filesystems were
created without any options. raid1 is about 7 TB, raid2 about 10TB. Both
filesystems are mounted with options '(rw,noatime,nodiratime,ihashsize=65536)'.

I used bonnie++ to benchmark both filesystems. Here are the results of
'bonnie++ -u root -f -n 10:0:0:1000':

Sequential Output: 82505 K/sec
Sequential Input : 102192 K/sec
Sequential file creation: 7184/sec
Random file creation    : 17277/sec

Sequential Output: 124802 K/sec
Sequential Input : 109158 K/sec
Sequential file creation: 123/sec
Random file creation    : 138/sec

As you can see, raid2's throughput is higher than raid1's. But the file
creation times are rather slow ...

Maybe the 143 million inodes cause this effect? Any idea how to avoid it?

Just another (xfs_)info about raid2:

meta-data=/dev/backuppc/backuppc isize=256 agcount=32, agsize=79691776 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=2550136832, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=32768, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0

Christoph Litauer                  litauer@xxxxxxxxxxxxxx
Uni Koblenz, Computing Center,     http://www.uni-koblenz.de/~litauer
Postfach 201602, 56016 Koblenz     Fon: +49 261 287-1311, Fax: -100 1311
PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2

<Prev in Thread] Current Thread [Next in Thread>