So here's where I got... First, I modified the systemd service config for deluged to limit it's memory and swap usage to around 8Gb, which seems to have gone well. It's still happy and no longer eats RAM.
But, it didn't help when it came time to moving large files from the SSD to the HDD at the end of the download. Load spiked to over 200, VMs got very upset, and arcstat suggested ARC usage went well over the 50% mark to 38Gb at one point, accompanied by a sudden increase in swap use by ~8Gb.
I next applied a bunch of recommendations in one hit because I'm impatient. I set `vm.dirty_ratio` and `vm.dirty_background_ratio` to 20% and 5%, to limit how much unwritten data can sit around waiting in memory, set zram swap to 16Gb, set the zfs_arc_cache_max to 25Gb, and zfs_arc_shrink_shift to 1, to more aggressively shrink the cache when memory is tight.
So far, it fared well with a single large copy. We'll see what happens when a whole sequence of them occur in a couple of hours time...
@stephen tinkering with a new (to me) laptop/tablet hybrid device recently has reminded me of what its like to (frequently!) get burned by Linux OOfM.. especially given how demanding Nix can be, even more so with ZFS in the equation!
Whilst tinkering and looking at how other people were handling it, I stumbled over this - https://github.com/rfjakob/earlyoom
Haven't tried it yet, but it felt promising enough to add it to "the list"!
It even has a #NixOS module 
