Re: defragmenting best practice?

[Duncan <1i5t5.duncan@cox.net>]

Dave posted on Wed, 20 Sep 2017 02:38:13 -0400 as excerpted:

> Here's my scenario. Some months ago I built an over-the-top powerful
> desktop computer / workstation and I was looking forward to really
> fantastic performance improvements over my 6 year old Ubuntu machine. I
> installed Arch Linux on BTRFS on the new computer (on an SSD). To my
> shock, it was no faster than my old machine. I focused a lot on Firefox
> performance because I use Firefox a lot and that was one of the
> applications in which I was most looking forward to better performance.
> 
> I tried everything I could think of and everything recommended to me in
> various forums (except switching to Windows) and the performance
> remained very disappointing.
> 
> Then today I read the following:
> 
>     Gotchas - btrfs Wiki https://btrfs.wiki.kernel.org/index.php/Gotchas
> 
>     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.)
> 
> Furthermore, on the same BTRFS Wiki page, it mentions the performance
> penalties of many snapshots. I am keeping 30 to 50 snapshots of the
> volume that contains the Firefox profile.
> 
> Would these two things be enough to turn top-of-the-line hardware into a
> mediocre-preforming desktop system? (The system performs fine on
> benchmarks -- it's real life usage, particularly with Firefox where it
> is disappointing.)
> 
> After reading the info here, I am wondering if I should make a new
> subvolume just for my Firefox profile(s) and not use COW and/or not keep
> snapshots on it and mount it with the autodefrag option.
> 
> As part of this strategy, I could send snapshots to another disk using
> btrfs send-receive. That way I would have the benefits of snapshots
> (which are important to me), but by not keeping any snapshots on the
> live subvolume I could avoid the performance problems.
> 
> What would you guys do in this situation?

[FWIW this is my second try at a reply, my first being way too detailed 
and going off into the weeds somewhere, so I killed it.]

That's an interesting scenario indeed, and perhaps I can help, since my 
config isn't near as high end as yours, but I run firefox on btrfs on 
ssds, and have no performance complaints.  The difference is very likely 
due to one or more of the following (FWIW I'd suggest a 4-3-1-2 order, 
tho only 1 and 2 are really btrfs related):

1) I make sure I consistently mount with autodefrag, from the first mount 
after the filesystem is created in ordered to first populate it, on.  The 
filesystem never gets fragmented, forcing writes to highly fragmented 
free space, in the first place.  (With the past and current effect of the 
ssd mount option under discussion to change, it's possible I'll get more 
fragmentation in the future after ssd doesn't try so hard to find 
reasonably large free-space chunks to write into, but it has been fine so 
far.)

2) Subvolumes and snapshots seemed to me more trouble than they were 
worth, particularly since it's the same filesystem anyway, and if it's 
damaged, it'll take all the subvolumes and snapshots with it.  So I don't 
use them, preferring instead to use real partitioning and more smaller 
fully separate filesystems, some of which aren't mounted by default (and 
root mounted read-only by default), so there's little chance they'll be 
damaged in a crash or filesystem bug damage scenario.  And if there /is/ 
any damage, it's much more limited in scope since all my data eggs aren't 
in the same basket, so maintenance such as btrfs check and scrub take far 
less time (and check far less memory) than they would were it one big 
pool with snapshots.  And if recovery fails too, the backups are likewise 
small filesystems the same size as the working copies, so copying the 
data back over takes far less time as well (not to mention making the 
backups takes less time in the first place, so it's easier to regularly 
update them).

3) Austin mentioned the firefox cache.  I honestly wouldn't know on it, 
since I have firefox configured to use a tmpfs for its cache, so it 
operates at memory speed and gets cleared along with its memory at every 
reboot or tmpfs umount.  My inet speed is fast enough I don't really need 
cache anyway, but it's nice to have it, operating at memory speed, within 
a single boot session... and to have it cleared on reboot.


4) This one was the biggest one for me for awhile.

Is firefox running in multi-process mode?  If you don't know, got to 
about:support, and look in the Application Basics section, at the 
Multiprocess Windows entry and the Web Content Processes entry.  When you 
have multiple windows open it should show something like 2/2 (for two 
windows open, tho you won't get 20/20 for 20 windows open) for windows, 
and n/7 (tho I believe the default is 4 instead of 7, I've upped mine) 
for content processes, with n going up toward 7 (or 4) if you have 
multiple tabs/windows open playing video or the like.

If you're stuck at a single process that'll be a *BIG* drag on 
performance, particularly when playing youtube full-screen or the like.  
There are various reasons you might get stuck at a single process, 
including extensions that aren't compatible with "electrolysis" (aka e10s, 
this being the mozilla code name for multi-process firefox), and the one 
that was my problem after I ensured all my extensions were e10s 
compatible -- I was trying to run the upstream firefox binary, which is 
now pulseaudio-only (no more direct alsa support), with apulse as a 
pulseaudio substitute, and apulse is apparently single-process-only 
(forcing multi-process would crash the tabs as soon as I tried navigating 
away from about:whatever to anything remote).

Once I figured that out I switched back to using the gentoo firefox ebuild 
and enabling the alsa USE flag instead of pulseaudio there.  That got 
multiprocess working, and it was was *MUCH* more responsive, as I figured 
it should be! =:^)

If you find you're stuck at single process (remember, check with at least 
two windows open) and need help with it, yell.  Because it'll make a 
*HUGE* difference.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman