Date: Fri, 07 Feb 2020 17:56:25 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile Message-ID: <bug-241848-227-XKCxst2t2w@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-241848-227@https.bugs.freebsd.org/bugzilla/> References: <bug-241848-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=3D241848 Mark Millard <marklmi26-fbsd@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marklmi26-fbsd@yahoo.com --- Comment #2 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Dave Evans from comment #1) If you get console messages something like (extracted example): . . . kernel: pid 7963 (strip), jid 0, uid 0, was killed: out of swap space This message text's detailed wording is frequently a misnomer. Do you also have any messages of the form: . . . sentinel kernel: swap_pager_getswapspace(32): failed If yes: you really were out of swap space. If no: you were not out of swap space, or at least it is highly unlikely that you were. FreeBSD kills processes for multiple potential reasons. For example: a) Still low on free RAM after a number of tries to increase it above a threshold. b) Slow paging I/O. c) . . . (I do not know the full list) . . . Unfortunately, FreeBSD is not explicit about the category of problem that leads to the kill activity that happens. You might learn more by watching how things are going via top or some such program or other way of monitoring. You likely will find the swap space not low. Below are some notes about specific tunables that might or might not be of help. (There may be more tunables that can help that I do not know about.) For (a) there is a way to test if it is the issue by adding to the number of tries before it gives up and starts killing things. That will either: 1) let it get more done before kills start 2) let it complete before the count is reached 3) make no significant difference (3) would imply that (b) or (c) are involved instead. (1) might be handled by having it do even more tries. For delaying how long free RAM staying low is tolerated, one can increase vm.pageout_oom_seq from 12 to larger. The management of slow paging I've less experience with but do have some notes about below. Examples follow that I use in contexts with sufficient RAM that I do not have to worry about out of swap/page space. These I've set in /etc/sysctl.conf . (Of course, I'm not trying to deliberately run out of RAM.) # # Delay when persisstent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 I'll note that figures like 1024 or 1200 or even more are possible. This is controlling how many tries at regaining sufficient free RAM that that level would be tolerated long-term. After that it starts Out Of Memory kills to get some free RAM. No figure is designed to make the delay unbounded. There may be large enough figures to effectively be bounded beyond any reasonable time to wait. As for paging I/O (WARNING: all the below tunables are specific to head (13), or was last I checked): # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: vm.pfault_oom_attempts=3D-1 (Note: In my context "plunty" really means sufficient RAM that paging is rare. But others have reported on using the -1 in contexts where paging was heavy at times and OOM kills had been happening that were eliminated by the assignment.) I've no experience with the below alternative to that -1 use: # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes: #vm.pfault_oom_attempts=3D ??? #vm.pfault_oom_wait=3D ??? # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) I'm not claiming that these 3 vm.???_oom_??? figures are always sufficient. Nor am I claiming that tunables are always available that would be sufficient. Nor that it is easy to find the ones that do exist that might help for specific OOM kill issues. I have seen reports of OOM kills for other reasons when both vm.pageout_oom_seq and vm.pfault_oom_attempts=3D-1 were in use. As I understand, FreeBSD did not report what kind of condition lead to the decision to do an OOM kill. So the above notes may or may-not help you. --=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-241848-227-XKCxst2t2w>