Re: defragmenting best practice?

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

On 2017-09-21 16:10, Kai Krakow wrote:
> Am Wed, 20 Sep 2017 07:46:52 -0400
> schrieb "Austin S. Hemmelgarn" <ahferroin7@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.