https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231457
Mark Millard <marklmi26-f...@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marklmi26-f...@yahoo.com --- Comment #6 from Mark Millard <marklmi26-f...@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=12 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=120 and one person with storage devices with I/O latency problems used something like vm.pageout_oom_seq=1024 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 . -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"