3 ms·
I've run into fun issues like FreeBSDs slab allocator not playing nicely with the ZFS/NFS workload on one specific server and having to drop down to having ZFS
by nightfly 4y ago
I've run into fun issues like FreeBSDs slab allocator not playing nicely with the ZFS/NFS workload on one specific server and having to drop down to having ZFS allocate memory in a different way that used about twices as much CPU to avoid random multi-second pauses on the whole system. Also had issues where kerberized NFS would get confused and something would crash so had to have random cron jobs to restart dying components, since FreeBSDs init system is so simple. Also arbitrary and short name length limits, I think in both bhyve in the past (couldn't use fqdns for VM names since that would have exceeded the limit) and something about zfs mountpoints ages ago (I think we ended up changing our naming and nested conventions to work around)
- eatbitseveryday 4y agoI’ve noticed this myself but didn’t dig into the delays I’ve seen. Interesting to learn it appears for others. How did you have ZFS change how it allocates memory?
- allanjude 4y agoThis was a bug in ZFS itself, and was resolved years ago: https://smartos.org/bugview/OS-6404 https://smartos.org/bugview/OS-6404 In FreeBSD 12.x and older, you could opt out of using UMA with: vfs.zfs.zio.use_uma=0, but that is not necessary
- eatbitseveryday 4y agoThanks. I still see multi-second pauses moving data over Samba to an encrypted ZFS pool. I’m using a 10Gbps network card, so the drives are the bottleneck (or so I thought, until seeing these delays). I’m on 13-RELEASE.