Date: Fri, 08 Jun 2018 15:18:29 +0100 From: Frank Leonhardt <frank2@fjl.co.uk> To: freebsd-questions@freebsd.org Subject: Re: Is it normal that a user can take down the whole system by using too much =?UTF-8?Q?memory=3F?= Message-ID: <3637bd5588f69098fd342cf29c8a81b4@roundcube.fjl.org.uk> In-Reply-To: <20180604104334.cfa2f9b307e52afff34c39ec@sohara.org> References: <1527977770.2651378.1394286400.0806CC5C@webmail.messagingengine.com> <01EE7EEA-03AC-4D71-BA08-B0CEA97EE720@thehowies.com> <1527981931.2670335.1394316280.09410FC9@webmail.messagingengine.com> <20180604104334.cfa2f9b307e52afff34c39ec@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-06-04 10:43, Steve O'Hara-Smith wrote: > On Sat, 02 Jun 2018 19:25:31 -0400 > Brennan Vincent <brennan@umanwizard.com> wrote: > >> Thanks John for the response -- this should help me solve my practical >> needs. >> >> I'm also curious, however, to learn more from an OS design >> perspective. > > Best way to do that is look at the code. > >> Why isn't it possible for the kernel to realize it should kill >> `eatmem` >> rather than make the system unusable? > > The code in vm_pageout.c that handles out of swap conditions tries > to kill the biggest process - by that it means the one estimated to > release > the most memory. To that end it skips processes in various states - > killed, > protected, system, non-running and then picks the biggest of the > remaining > processes to kill. > > One thing that may cause the random chaos you see is that killing a > process takes time, especially if that process has swapped out pages, > if > something else calls for memory it has finished dying then the next > biggest > process will get killed even though the process responsible has already > been killed (after all it might be locked up and failing to die). You might want to look at this: http://blog.frankleonhardt.com/2011/large-swap-files-on-freebsd-die-with-mystery-killed-howto-add-lots-of-swap-space/ Regards, Frank.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3637bd5588f69098fd342cf29c8a81b4>