Strange slowdown when cache devices enabled in ZFS
Freddie Cash
fjwcash at gmail.com
Thu Apr 25 15:51:45 UTC 2013
I haven't had a chance to run any of the DTrace scripts on any of my ZFS
systems, but I have narrowed down the issue a bit.
If I set primarycache=all and secondarycache=all, then adding an L2ARC
device to the pool will lead to zfskern{l2arc_feed_thread} taking up 100%
of one CPU core and stalling I/O to the pool.
If I set primarycache=all and secondarycache=metadata, then adding an L2ARC
device to the pool speeds things up (zfs send/recv saturates a 1 Gbps link;
and the nightly rsync backups run finishes 4 hours earlier).
I haven't tested the other two combinations (metadata/metadata;
metadata/all) as yet.
This is consistent across two ZFS systems so far:
- 8-core Opteron 6100-series CPU with 48 GB of RAM; 44 GB ARC, 40 GB
metadata limit; 3x raidz2
- 2x 8-core Opteron 6100-series CPU with 128 GB of RAM; 64 GB ARC, 60 GB
metadata limit; 5x raidz2
Still reading up on dtrace/hwpmc as time permits. Just wanted to pass
along the above to show I haven't forgotten about this yet. :) $JOB/$LIFE
slows things down sometimes. :)
--
Freddie Cash
fjwcash at gmail.com
More information about the freebsd-fs
mailing list