From owner-freebsd-hackers Fri Aug 8 22:13:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA07900 for hackers-outgoing; Fri, 8 Aug 1997 22:13:30 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA07895 for ; Fri, 8 Aug 1997 22:13:23 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id XAA00459 for hackers@freebsd.org; Fri, 8 Aug 1997 23:13:22 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id TAA16774 for ; Fri, 8 Aug 1997 19:08:51 -0600 (MDT) Date: Fri, 8 Aug 1997 19:08:50 -0600 (MDT) From: Marc Slemko To: hackers@freebsd.org Subject: out of swap space but nothing killed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We have a 2.2-stable machine w/96 megs RAM and 320 megs swap running innd. There is something funny going on, and every once in a while innd seems to start to swallow memory. It appears to be a bug in innd or one of the patches we have applied. So far so good. FreeBSD can do nothing about innd croaking when it runs out of memory. However, when the machine runs out of swap innd will only sometimes die. Other times the box will sit there, still pingable but dead in the water. innd is not killed. I get a: swap_pager: out of swap space and that is all. Not even responsive to ctrl-alt-del on the console. The source seems to imply that unless the machine gets deadlocked somewhere it should kill the largest process and go on with life. Has anyone else seen similar behavior? Known issue? Perhaps space isn't being reclaimed properly from the cache in an out-of-memory situation, resulting in a deadlock: ((cnt.v_free_count + cnt.v_cache_count) < cnt.v_free_min)) { My only two guesses are that either the above is causing a problem or it simply isn't getting to this part of vm_pageout.c. The pageout daemon simply not getting woken up from its tsleep when it should be? Could increasing v_free_min help avoid this situation? Yes, knocking down the ulimits for innd to something that leaves a bit of swap free would probably avoid the problem. Guess I may have to do that.