Re: Performance Issues

[Martin <m_btrfs@ml1.co.uk>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20/09/14 09:23, Marc Dietrich wrote:
> Am Freitag, 19. September 2014, 13:51:22 schrieb Holger
> Hoffstätte:
>> 
>> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
>> 
>>> I have a particularly uncomplicated setup (a desktop PC with a
>>> hard disk) and I'm seeing particularly slow performance from
>>> btrfs.  A `git status` in the linux source tree takes about 46
>>> seconds after dropping caches, whereas on other machines using
>>> ext4 this takes about 13s.  My mail client (evolution) also
>>> seems to perform particularly poorly on this setup, and my
>>> hunch is that it's spending a lot of time waiting on the
>>> filesystem.
>> 
>> This is - unfortunately - a particular btrfs
>> oddity/characteristic/flaw, whatever you want to call it. git
>> relies a lot on fast stat() calls, and those seem to be
>> particularly slow with btrfs esp. on rotational media. I have the
>> same problem with rsync on a freshly mounted volume; it gets fast
>> (quite so!) after the first run.
> 
> my favorite benchmark is "ls -l /usr/bin":
> 
> ext4:     0.934s btrfs:   21.814s


So... On my old low power slow Atom SSD ext4 system:

time ls -l /usr/bin

real    0m0.369s

user    0m0.048s
sys     0m0.128s

Repeated:

real    0m0.107s

user    0m0.040s
sys     0m0.044s

and that is for:

# ls -l /usr/bin | wc
   1384   13135   88972


On a comparatively super dual core Athlon64 SSD btrfs three disk btrfs
raid1 system:

real    0m0.103s

user    0m0.004s
sys     0m0.040s

Repeated:

real    0m0.027s

user    0m0.008s
sys     0m0.012s

For:

# ls -l /usr/bin | wc
   1449   13534   89024


And on an identical comparatively super dual core Athlon64 HDD
'spinning rust' btrfs two disk btrfs raid1 system:

real    0m0.101s

user    0m0.008s
sys     0m0.020s

Repeated:

real    0m0.020s

user    0m0.004s
sys     0m0.012s

For:

# ls -l /usr/bin | wc
   1161   10994   79350


So, no untoward concerns there.

Marc:

You on something really ancient and hopelessly fragmented into oblivion?



> also mounting large partitons (several 100Gs) takes lot of time on
> btrfs.

I've noticed that also for some 16TB btrfs raid1 mounts, btrfs is not
as fast as mounting ext4 but then again all very much faster than
mounting ext4 when a fsck count is tripped!...

So, nothing untoward there.


For my usage, controlling fragmentation and having some automatic
mechanism to deal with pathological fragmentation with such as sqlite
files are greater concerns!

(Yes, there is the manual fix of NOCOW... I also put such horrors into
tmpfs and snapshot that... All well and good but all unnecessary admin
tasks!)


Regards,
Martin


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlQdhBwACgkQ+sI3Ds7h07f/VwCgkHPjrIkBkWh5zrKwvN7fXalZ
LWcAoIbLFEoc7iTNLzgSChNvnYatIkuZ
=YlDI
-----END PGP SIGNATURE-----