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 $ 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
