Am Thu, 21 Sep 2017 22:10:13 +0200 schrieb Kai Krakow <hurikha...@gmail.com>:
> Am Wed, 20 Sep 2017 07:46:52 -0400 > schrieb "Austin S. Hemmelgarn" <ahferro...@gmail.com>: > > > > Fragmentation: Files with a lot of random writes can become > > > heavily fragmented (10000+ extents) causing excessive multi-second > > > spikes of CPU load on systems with an SSD or large amount a RAM. > > > On desktops this primarily affects application databases > > > (including Firefox). Workarounds include manually defragmenting > > > your home directory using btrfs fi defragment. Auto-defragment > > > (mount option autodefrag) should solve this problem. > > > > > > Upon reading that I am wondering if fragmentation in the Firefox > > > profile is part of my issue. That's one thing I never tested > > > previously. (BTW, this system has 256 GB of RAM and 20 cores.) > > Almost certainly. Most modern web browsers are brain-dead and > > insist on using SQLite databases (or traditional DB files) for > > everything, including the cache, and the usage for the cache in > > particular kills performance when fragmentation is an issue. > > At least in Chrome, you can turn on simple cache backend, which, I > think, is using many small instead of one huge file. This suit btrfs > much better: > > chrome://flags/#enable-simple-cache-backend > > > And then I suggest also doing this (as your login user): > > $ cd $HOME > $ mv .cache .cache.old > $ mkdir .cache > $ lsattr +C .cache Oops, of course that's chattr, not lsattr > $ rsync -av .cache.old/ .cache/ > $ rm -Rf .cache.old > > This makes caches for most applications nocow. Chrome performance was > completely fixed for me by doing this. > > I'm not sure where Firefox puts its cache, I only use it on very rare > occasions. But I think it's going to .cache/mozilla last time looked > at it. > > You may want to close all apps before converting the cache directory. > > Also, I don't see any downsides in making this nocow. That directory > could easily be also completely volatile. If something breaks due to > no longer protected by data csum, just clean it out. -- Regards, Kai Replies to list-only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
