On 2017-09-21 16:10, Kai Krakow wrote:
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:
That's correct. The traditional cache in Chrome and Chromium uses a
single SQLite database for storing all the cache data and metadata (just
like FIrefox did last time I checked). The simple cache backend instead
uses the filesystem to handle allocations and uses directory hashing to
speed up look ups of items, which actually means that even without BTRFS
involved, it will usually be faster (both because it allows concurrent
access unlike SQLite, and because it's generally faster to parse a
multi-level directory hash than an SQL statement).
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.
I'm pretty sure that is correct.
You may want to close all apps before converting the cache directory.
At a minimum, you'll have to restart them to get them to use the new
location.
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.
Indeed, anything that is storing data here that can't be regenerated
from some other source is asking for trouble, sane backup systems don't
include ~/.cache, and it's quite often one of the first things
recommended for deletion when trying to free up disk space.
--
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
