11.11.2021 11:43, Chris Ross wrote: >> On Nov 10, 2021, at 23:35, Chris Ross <cross+free...@distal.com> wrote: >> >> Hey all. I have a system that I’m trying to do some intensive CPU and I/O >> on. FreeBSD 13.0-RELEASE, amd64, 128GB RAM, hardware RAID1 OS volume, and a >> large (40TB) zpool where most of the I/O is happening. >> >> Initially, it was failing for me because it was running out of swap space. >> It had only the normal small (4-8G) swap partition, so I resized the >> filesystems on the root disk and now have 400+GB swap. The system had >> frozen up and I wasn’t able to log in. When I go to the console, I find a >> long list of: >> >> swap_pager: cannot allocate bio >> >> lines. I was able to log into the console as root and pstat -s shows the >> swap minimally used (7.5GB used). Attempting a “zpool status” at that point >> locked up. I don’t know if the problem is the memory subsystem, or zfs. >> >> But, based on the error, is there perhaps some kernel parameter I can tune >> that might prevent the swap pager from encountering that error? > > Moving to freebsd-fs. More information makes it looks more like a ZFS > problem than anything else. > > I am able to log into another root virtual console, and I can run ps (shows > many things, including dozens of "cron: running job (cron)” jobs, in D > state), and I’m able to wander around the root disk (3T ufs filesystem) > without trouble. But, as mentioned above the “zpool status” is hung, and I > suspect if I tried to access anything in that filesystem it would hang to. > Those cron jobs, which aren’t anything I added, I assume are just system > “check around the system” cron jobs that are getting stuck there. > > So, if anyone has any suggestions. I can leave this system stuck like this > for a little while, but I’ll probably want to bring it back before the end of > the day tomorrow. (I’m US EST, so it’s almost midnight here. I’ll check in > on email for suggestions or ideas in the morning.) > > Thanks all.
If you have debugging symbols for your kernel and DDB in the kernel, you could drop to DDB with Ctrla-Alt-ESC and try to "call doadump" in the debugger to produce crashdump before reboot for post-mortem analysis. Are you sure you did not enable file-backed swap?
