From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 03:31:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 156C637B401 for ; Thu, 27 Mar 2003 03:31:46 -0800 (PST) Received: from office.advantagecom.net (office.advantagecom.net [207.109.186.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B3B843F75 for ; Thu, 27 Mar 2003 03:31:45 -0800 (PST) (envelope-from andykinney@advantagecom.net) Received: from SCSI-MONSTER (andy.advantagecom.net [207.109.186.200] (may be forged)) by office.advantagecom.net (8.9.3/8.9.3) with ESMTP id DAA22305; Thu, 27 Mar 2003 03:31:39 -0800 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: Terry Lambert Date: Thu, 27 Mar 2003 03:31:48 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Message-ID: <3E8270A4.12784.2592605@localhost> Priority: normal In-reply-to: <3E822424.C0D6E8E9@mindspring.com> X-mailer: Pegasus Mail for Win32 (v3.12c) X-Spam-Status: No, hits=-21.8 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared mem and panics when out of PV Entries X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andykinney@advantagecom.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 11:31:47 -0000 On 26 Mar 2003, at 14:05, Terry Lambert wrote: > It's to ensure an allocation of a PV Entry *DOES NOT FAIL*, even > when you *are* completely starved. That's the whole point: to > move the KVA space pressure off onto some *other* system that > *also* does not preallocate its resources, and expect that that > failure will turn into a benign "Apache: fork failed" log message, > instead of being a panic. > > We want to get rid of the panic. > > Once we know what works around something, we can fix it later, > but the important part is to know what the something *is*, first. > > Make sense? Ok. Now it makes perfect sense. I guess I didn't understand the point of preallocating via MINPV until now. My thanks to you and Mr. Sysoev for all the assistance you've provided. In particular, thanks for the in depth lesson in memory management. It's not like there's much in the way of documentation out there, so all the information and explanations that you have provided have given me much more insight into the BSD memory mangement system than I had before. At this point, I'm not so certain that I was right with regards to the root cause of the panic as you have provided a very thorough argument to the contrary. I do think it is sound advice to take the approach you have suggested even if for no other reason than to determine definitively what is the root cause of the panic. So, I think I'll do that little preallocation trick you showed me, turn on crash dumps (4GB crash dumps are a royal pain, but useful in this case), and unleash Apache. If you're right, then I'll get some other panic or non-panic error message at some point. I'll let you know how it goes. It may be a few days until I get back to the list with results since I have to schedule this kind of work in advance due to the downtime involved. As far as MySQL goes, I'll look into compiling it with FreeBSD native threads and replacing the prepackaged binary we're currently using. That should allow me to bump up KVA_PAGES without incident if I understand correctly. That appears to be much easier than recoding the Linux threads module. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net