Date: Wed, 15 Dec 2010 17:28:28 +0200 From: George Mamalakis <mamalos@eng.auth.gr> To: Kostik Belousov <kostikbel@gmail.com> Cc: stable@freebsd.org Subject: Re: vm.swap_reserved toooooo large? Message-ID: <4D08DE9C.1060108@eng.auth.gr> In-Reply-To: <20101215135143.GY33073@deviant.kiev.zoral.com.ua> References: <4D08A0A1.40205@eng.auth.gr> <alpine.BSF.2.00.1012151220260.10096@mail.fig.ol.no> <4D08C61C.4090006@eng.auth.gr> <20101215135143.GY33073@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15/12/2010 15:51, Kostik Belousov wrote: > On Wed, Dec 15, 2010 at 03:43:56PM +0200, George Mamalakis wrote: >> On 15/12/2010 13:26, Trond Endrest??l wrote: >>> On Wed, 15 Dec 2010 13:04+0200, George Mamalakis wrote: >>> >>>> I was testing a program that would exhaust all my memory (in C++), >>>> and when this would happen, it would call set_new_handler() along >>>> with one of my functions that would inform the user about the lack >>>> of memory and then it would exit the program. Instead, the program >>>> was force-killed by the kernel (signal 9) and I was informed that: >>> If all your process' memory is exhausted, then there is no memory left >>> for the runtime system for doing I/O and the other stuff you want. >>> Next, unless I'm on drugs, maybe you should call set_new_handler() >>> before you actually run out of memory. Just my $0.02. >>> >>> >>> Trond. >>> >>> >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> Trond, >> >> My problem was not that the program was force-killed, my problem was >> that the system reserved 500G+ of swap, even though the total size is 4G. > Read tuning(7), in particular, the description of vm.overcommit sysctl. Thank you Kostik, it proves that I was missing something fundamental after all :) On the other hand, what I noticed was that during the process of allocating the huge amount of memory, root processes got killed, which at first seems rational, on the other hand it is a bit strange. My dmesg shows: pid 1732 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) pid 2227 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) swap zone exhausted, increase kern.maxswzone pid 1544 (console-kit-daemon), uid 0, was killed: out of swap space swap zone exhausted, increase kern.maxswzone pid 2864 (memory), uid 1001, was killed: out of swap space swap zone exhausted, increase kern.maxswzone pid 1676 (gconf-helper), uid 1001, was killed: out of swap space where one can see that pid 1544 was killed before 2864, which is the process that caused all this mess. Yes, I know that I should use limits so as not to allow such things to happen, but on the other hand, if a malicious user causes such a situation he/she may gain access to information through core-dumps on root processes, AND cause DoS attacks. If it were for me, I would sort all processes based on their memory consumption, and start by killing those that have the highest value (top-bottom) that are NOT owned by root (just a thought, without thinking about it too much), so as to prevent such situations from happening. No need to answer my questions, they are rhetorical. I assume that there must be some good reason behind this behavior. Thanx again for all the help. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D08DE9C.1060108>