From owner-freebsd-questions@FreeBSD.ORG Mon Jan 22 14:12:20 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A2B316A403 for ; Mon, 22 Jan 2007 14:12:20 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id D3F2713C442 for ; Mon, 22 Jan 2007 14:12:19 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Mon, 22 Jan 2007 09:12:19 -0500 id 00056424.45B4C643.000105F0 Date: Mon, 22 Jan 2007 09:12:18 -0500 From: Bill Moran To: "peter" Message-Id: <20070122091218.6de55170.wmoran@collaborativefusion.com> In-Reply-To: <01a101c73df9$34198ff0$560ea8c0@rzcpei> References: <003b01c73b71$b1e5a930$560ea8c0@rzcpei> <20070119091339.6a0229f1.wmoran@collaborativefusion.com> <01a101c73df9$34198ff0$560ea8c0@rzcpei> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.0 (GTK+ 2.10.7; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-questions@freebsd.org Subject: Re: no pv entries: increase vm.pmap.shpgperproc X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 14:12:20 -0000 In response to "peter" : > > In response to "peter" : > > > Hi, > > > My freebsd box runs the apache httpd2.0 server, postgresql8.1server, > > > Recently, I got the below info in /var/crash. > > > “Dump header from device /dev/da0s1b > > > Architecture: i386 > > > Architecture Version: 2 > > > Dump Length: 1073127424B (1023 MB) > > > Blocksize: 512 > > > Dumptime: Wed Jan 17 16:39:08 2007 > > > Hostname: myhost.mydomain.com > > > Magic: FreeBSD Kernel Dump > > > Version String: FreeBSD 6.0-RELEASE #0: Tue Apr 25 15:07:33 CST 2006 > > > peter@myhost.mydomain.com:/usr/src/sys/i386/compile/MYKNL > > > Panic String: no pv entries: increase vm.pmap.shpgperproc > > > Dump Parity: 2383301964 > > > Bounds: 49 > > > Dump Status: good” > > > I had searched in google, but I didn’t know how to do. > > > > You _should_ be able to raise the vm.pmap.shpgperproc sysctl to prevent > > the problem -- but there doesn't seem to be any such sysctl. I'm not sure > > what's going on here, but it seems to me that a PR is in order. > > I had ever added the line "kern.vm.pmap.shpgperproc=4096" to /boot/loader.conf , > but it seems to be ineffective. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108121 > > Failing that, you could set the following in your kernel config: > > options PMAP_SHPGPERPROC=250 > > and rebuild/reinstall your kernel. > > > > The default value is 200, so I expect 250 will be enough of a bump to > > fix the problem. If it's not, raise it a little higher and try again. > > I don't know of any way to tell exactly what this value should be other > > than trial and error. I've seen warnings that raising this value too > > high can result in an unbootable kernel, so take care to understand how > > to recover from the installation of an unbootable kernel. > > How to know the default value? Experiment. You can also look at the PV line in the sysctl vm.zone, but I'm not sure how to interpret that information. > The website on the box has about 22000 visits every day, so i think the > physical memory size maybe small. OK. > I configured httpd.conf like this: > .... > KeepAlive Off > .... > > StartServers 8 > MinSpareServers 3 > MaxSpareServers 5 > ServerLimit 170 > MaxClients 160 > MaxRequestsPerChild 300 > > ..... If this is a dedicated web server, you sure are configuring it wrong. First off, you tell it to start 8 workers, then immediately kill off three of them to meet the MaxSpareServers. That's pretty minor, however, as it only happens at startup. MaxSpareServers of 5 is pretty low for a busy webserver. If the site is seeing a lot of traffic, or the traffic is erratic, you're forcing Apache to try to constantly tune itself to exactly what the load is. If this server is dedicated to webserving, you'd do better to raise MaxSpareServers to something like 25, so you have some spare capacity when the load spikes instead of forcing Apache to do a lot of forking, then kill off a lot of processes, then fork a lot of them again ... But that discussion belongs on the Apache lists ... -- Bill Moran Collaborative Fusion Inc.