I couldn't find any obvious cause other than persistently high kernel_task CPU usage averaging 30-140%, with various apps showing similar high CPU usage with no obvious pattern. In my case the main culprits were securityd, corespotlightd, Plex Media Scanner and Mail.app, but I don't believe any of these were to blame. Killing these would temporarily ease the problem only for it to return again. The only option that "solved" the problem was exporting all pools.
I often see high-ish kernel_task CPU usage on v2.1.0 as well, but this is usually under heavier load, tops out around 30%, and tends to ease off as the ARC fills up. Under v2.1.6 I was seeing that kind of CPU usage under extremely light load after letting the ARC fill up (to around 11.5gb). This included just trying to listen to some music, which was impossible, as coreaudiod handling my external audio driver kept locking up. I see no reason why ZFS' CPU usage should be so absurdly high? Indeed, one of my main reasons for wanting to upgrade was the performance improvements made to encryption which is supposed to solve or at least reduce the high CPU usage (and seems to work as expected on Linux).
My setup includes a large number of encrypted datasets across two pools (one is main storage, the other is purely for backups), and I run all user accounts from datasets on main storage, except for my administrator account (which is on the internal APFS startup disk). I'm running on macOS 10.15.7 though I'm planning to upgrade macOS soon. Also worth noting that I did not upgrade either of my pools in case that meant I couldn't downgrade.
Sorry I can't provide more in the way of useful information, but when I say my system was barely usable I mean it; Activity Monitor barely ran, I could only get CPU usage values by running top in Terminal, and even that was unbearably slow.
Here's a representative sample of the settings on one of my datasets:
- Code: Select all
NAME PROPERTY VALUE SOURCE
zdata/haravikk type filesystem -
zdata/haravikk creation Mon Jan 17 13:07 2022 -
zdata/haravikk used 38.0G -
zdata/haravikk available 182G -
zdata/haravikk referenced 37.8G -
zdata/haravikk compressratio 1.05x -
zdata/haravikk mounted no -
zdata/haravikk quota none default
zdata/haravikk reservation none default
zdata/haravikk recordsize 128K default
zdata/haravikk mountpoint /Users/haravikk local
zdata/haravikk sharenfs off default
zdata/haravikk checksum on default
zdata/haravikk compression zstd inherited from zdata
zdata/haravikk atime on default
zdata/haravikk devices on default
zdata/haravikk exec on default
zdata/haravikk setuid on default
zdata/haravikk readonly off local
zdata/haravikk zoned off default
zdata/haravikk snapdir hidden default
zdata/haravikk aclmode discard default
zdata/haravikk aclinherit restricted default
zdata/haravikk createtxg 242 -
zdata/haravikk canmount on local
zdata/haravikk xattr sa inherited from zdata
zdata/haravikk copies 2 inherited from zdata
zdata/haravikk version 5 -
zdata/haravikk utf8only on -
zdata/haravikk normalization formD -
zdata/haravikk casesensitivity insensitive -
zdata/haravikk vscan off default
zdata/haravikk nbmand off default
zdata/haravikk sharesmb off default
zdata/haravikk refquota none default
zdata/haravikk refreservation none default
zdata/haravikk guid 13847935460132862844 -
zdata/haravikk primarycache all default
zdata/haravikk secondarycache all default
zdata/haravikk usedbysnapshots 0B -
zdata/haravikk usedbydataset 37.8G -
zdata/haravikk usedbychildren 205M -
zdata/haravikk usedbyrefreservation 0B -
zdata/haravikk logbias latency default
zdata/haravikk objsetid 271 -
zdata/haravikk dedup off default
zdata/haravikk mlslabel none default
zdata/haravikk sync standard default
zdata/haravikk dnodesize auto inherited from zdata
zdata/haravikk refcompressratio 1.05x -
zdata/haravikk written 37.8G -
zdata/haravikk logicalused 19.6G -
zdata/haravikk logicalreferenced 19.4G -
zdata/haravikk volmode default default
zdata/haravikk filesystem_limit none default
zdata/haravikk snapshot_limit none default
zdata/haravikk filesystem_count none default
zdata/haravikk snapshot_count none default
zdata/haravikk snapdev hidden default
zdata/haravikk acltype nfsv4 default
zdata/haravikk context none default
zdata/haravikk fscontext none default
zdata/haravikk defcontext none default
zdata/haravikk rootcontext none default
zdata/haravikk relatime on inherited from zdata
zdata/haravikk redundant_metadata all default
zdata/haravikk overlay on default
zdata/haravikk encryption aes-256-gcm -
zdata/haravikk keylocation prompt local
zdata/haravikk keyformat passphrase -
zdata/haravikk pbkdf2iters 350000 -
zdata/haravikk encryptionroot zdata/haravikk -
zdata/haravikk keystatus unavailable -
zdata/haravikk special_small_blocks 0 default
zdata/haravikk com.apple.browse on inherited from zdata
zdata/haravikk com.apple.ignoreowner off inherited from zdata
zdata/haravikk com.apple.mimic hfs inherited from zdata
zdata/haravikk com.apple.devdisk on inherited from zdata
The pool has no physical redundancy (terrible I know but it's just a stop-gap till I get a new enclosure so I can add more disks) which is why most of the datasets have copies=2 so self-healing is still possible (media datasets don't as it would require too much storage). My backup pool however has physical redundancy and is just used as a target for raw zfs send/receive while discarding extra copies. I don't usually notice any increase in CPU usage during sends to zbackup, presumably since it's raw (so nothing should be getting decrypted/encrypted) so it never goes above what I would see for a similar amount of reading from zdata only.