Re: Performance Issues

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]

On 2014-09-19 08:18, Rob Spanton wrote:
> Hi,
>
> 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.
>
> I've tried mounting with noatime, and this has had no effect.  Anyone
> got any ideas?
>
> Here are the things that the wiki page asked for [1]:
>
> uname -a:
>
>          Linux zarniwoop.blob 3.16.2-200.fc20.x86_64 #1 SMP Mon Sep 8
>          11:54:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> btrfs --version:
>
>          Btrfs v3.16
>
> btrfs fi show:
>
>          Label: 'fedora'  uuid: 717c0a1b-815c-4e6a-86c0-60b921e84d75
>          	Total devices 1 FS bytes used 1.49TiB
>          	devid    1 size 2.72TiB used 1.50TiB path /dev/sda4
>
>          Btrfs v3.16
>
> btrfs fi df /:
>
>          Data, single: total=1.48TiB, used=1.48TiB
>          System, DUP: total=32.00MiB, used=208.00KiB
>          Metadata, DUP: total=11.50GiB, used=10.43GiB
>          unknown, single: total=512.00MiB, used=0.00
>
> dmesg dump is attached.
>
> Please CC any responses to me, as I'm not subscribed to the list.
>
> Cheers,
>
> Rob
>
> [1] https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list
>
>
WRT the performance of Evolution, the issue is probably fragmentation of 
the data files.  If you run the command:
# btrfs fi defrag -rv /home
you should see some improvement in evolution performance (until you get 
any new mail that is).  Evolution (like most graphical e-mail clients 
these days) uses sqlite for data storage, and sqlite database files are 
one of the known pathological cases for COW filesystems in general; the 
solution is to mark the files as NOCOW (see the info about VM images in 
[1] and [2], the same suggestions apply to database files).

As for git, I haven't seen any performance issues specific to BTRFS; are 
you using any compress= mount option? zlib based compression is known to 
cause serious slowdowns.  I don't think that git uses any kind of 
database for data storage.  Also, if the performance comparison is from 
other systems, unless those systems have the EXACT same hardware 
configuration, they aren't really a good comparison.  Unless the pc this 
is on is a relatively recent system (less than a year or two old), it 
may just be hardware that is the performance bottleneck.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]