Date: Mon, 01 Oct 2018 19:13:17 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 231457] Out of swap space on ZFS Message-ID: <bug-231457-227-nrdn2OfdTG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-231457-227@https.bugs.freebsd.org/bugzilla/> References: <bug-231457-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231457 Mark Millard <marklmi26-fbsd@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marklmi26-fbsd@yahoo.com --- Comment #6 from Mark Millard <marklmi26-fbsd@yahoo.com> --- As I understand any conditions that lead to sustained low free RAM via pressure from one or more processes that keep active RAM usage high leads to killing of processes to free memory. The default vm.pageout_oom_seq=3D12 can be increased to increase how long the low free RAM condition is tolerated. (It increases how many attempts to free RAM are made first.) I assign vm.pageout_oom_seq in /etc/sysctl.conf . FreeBSD does not swap out processes that stay active. This is documented in the book published by McKusic, Neville-Neil, and Watson (2nd edition, last names listed). So if one or more keep active RAM use high, free RAM use tends to stay low. There can be lots of swap available and the process killing can still happen. The console log messages produced for this case is very misleading via referencing out of swap instead of referencing a sustained period of low free RAM. Real "out of swap" conditions tend to also have messages of the form: Aug 5 17:54:01 sentinel kernel: swap_pager_getswapspace(32): failed On small board computers such as ARM boards I've been using vm.pageout_oom_seq=3D120 and one person with storage devices with I/O latency problems used something like vm.pageout_oom_seq=3D1024 to allow -j4 buildworld buildkernel to work. (No attempt at approximating the smallest value that would have worked.) There was a long 2018 Jun. through Sep. freebsd-arm list exchange under various subjects that eventually exposed this vm.pageout_oom_seq control and FreeBSD's swapping criteria that I noted above. This does not address why Free RAM is low over a sustained period, it just makes the system more tolerant of such. It could be that there are also other mechanisms that do not involve vm.pageout_oom_seq . --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-231457-227-nrdn2OfdTG>