From owner-freebsd-questions@FreeBSD.ORG Mon Oct 27 20:44:05 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 793F11065673 for ; Mon, 27 Oct 2008 20:44:05 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CBB2B8FC22 for ; Mon, 27 Oct 2008 20:44:04 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.3/8.14.3) with ESMTP id m9RKhoG3010652; Mon, 27 Oct 2008 20:43:58 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.7.2 smtp.infracaninophile.co.uk m9RKhoG3010652 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infracaninophile.co.uk; s=200708; t=1225140238; bh=y5ot/g7KVSqQpQ j6v/ts+K7Z0LH68//ltex1glg4kw0=; h=Message-ID:Date:From:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type:Cc:Content-Type: Date:From:In-Reply-To:Message-ID:Mime-Version:References:To; z=Mes sage-ID:=20<49062801.9090805@infracaninophile.co.uk>|Date:=20Mon,=2 027=20Oct=202008=2020:43:45=20+0000|From:=20Matthew=20Seaman=20|Organization:=20Infracaninophile|User -Agent:=20Thunderbird=202.0.0.17=20(X11/20080929)|MIME-Version:=201 .0|To:=20=3D?ISO-8859-1?Q?Francis_Dub=3DE9?=3D=20|CC:=20freebsd-questions@freebsd.org|Subject:=20Re:=20coll ecting=20pv=20entries=20--=20suggest=20increasing=20PMAP_SHPGPERPRO C|References:=20<49060AE0.3000301@optiksecurite.com>|In-Reply-To:=2 0<49060AE0.3000301@optiksecurite.com>|X-Enigmail-Version:=200.95.6| Content-Type:=20multipart/signed=3B=20micalg=3Dpgp-sha256=3B=0D=0A= 20protocol=3D"application/pgp-signature"=3B=0D=0A=20boundary=3D"--- ---------enig330E7118D7B77CAC47E7C33E"; b=Ybg1fxCtPEsOdRcsUiDTimnlK 6RK9/jAbk+K2gDeS1gdLwc1uLEU+ehf9vkkl0mL1e/RHaa/11bhtJL3vMqDSvYWf1Iu K2XFAdvAoG6SWuDXj016TYWlnRVhA+pTPhMyog7L7dl1k6GStW/cuI2nHHgPl0SESvs kQxk53bCBsE0= Message-ID: <49062801.9090805@infracaninophile.co.uk> Date: Mon, 27 Oct 2008 20:43:45 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.17 (X11/20080929) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Francis_Dub=E9?= References: <49060AE0.3000301@optiksecurite.com> In-Reply-To: <49060AE0.3000301@optiksecurite.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig330E7118D7B77CAC47E7C33E" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (smtp.infracaninophile.co.uk [IPv6:::1]); Mon, 27 Oct 2008 20:43:58 +0000 (GMT) X-Virus-Scanned: ClamAV 0.94/8512/Mon Oct 27 18:47:35 2008 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,NORMAL_HTTP_TO_IP,NO_RELAYS,URIBL_RHS_DOB autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-questions@freebsd.org Subject: Re: collecting pv entries -- suggest increasing 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, 27 Oct 2008 20:44:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig330E7118D7B77CAC47E7C33E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Francis Dub=E9 wrote: > Hi everyone, >=20 > I'm running a a webserver on FreeBSD (6.2-RELEASE-p6) and I have this=20 > error in my logs : >=20 > collecting pv entries -- suggest increasing PMAP_SHPGPERPROC >=20 > I've read that this is mainly caused by Apache spawning too many=20 > processes. Everyone seems to suggest to decrease the MaxClients=20 > directive in Apache(set to 450 at the moment), but here's the=20 > problem...i need to increase it ! During peaks all the processes are in= =20 > use, we even have little drops sometime because there isn't enough=20 > processes to serve the requests. Our traffic is increasing slowly over = > time so i'm affraid that it'll become a real problem soon. Any tips on = > how I could deal with this situation, Apache's or FreBSD's side ? >=20 > Here's the useful part of my conf : >=20 > Apache/2.2.4, compiled with prefork mpm. > httpd.conf : > [...] > > ServerLimit 450 > StartServers 5 > MinSpareServers 5 > MaxSpareServers 10 > MaxClients 450 > MaxRequestsPerChild 0 > >=20 > KeepAlive On > KeepAliveTimeout 15 > MaxKeepAliveRequests 500 > [...] You don't say what sort of content you're serving, but if it is PHP, Ruby-on-Rails, Apache mod_perl or similar dynamic content then=20 here's a very useful strategy. Something like 25-75% of the HTTP queries on a dynamic web site will typically be for static files: images, CSS, javascript, etc. An instance of Apache padded out with all the machinery to run all that dynamic code is not the ideal server for the static stuff. In fact, if you install one of the special super-fast webservers optimised for static content, you'll probably be able to answer all those=20 requests from a single thread of execution of a daemon substantially slimmer than apache. I like nginx for this purpose, but lighttpd is another candidate, or you can even use a 2nd highly optimised=20 instance of apache with almost all of the loadable modules and other=20 stuff stripped out. The tricky bit is managing to direct the HTTP requests to the appropriate= server. With nginx I arrange for apache to bind to the loopback interface and nginx handles the external network i/f, but the document root for both servers is the same directory tree. Then I'd filter off requests for, say, PHP pages using a snippet like so in nginx.conf: location ~ \.php$ { proxy_pass http://127.0.0.1; } So all the PHP gets passed through to Apache, and all of the other conten= t (assumed to be static files) is served directly by nginx[1]. It also helps if you set nginx to put an 'Expires:' header several days or weeks in the future for all the static content -- that way the client browser will cache it locally and it won't even need to connect back to your server and try doing an 'if-modified-since' HTTP GET on page refreshes. The principal effect of this is that Apache+PHP basically spends all=20 it's time doing the heavy lifting it's optimised for, and doesn't get dis= tracted by all the little itty-bitty requests. So you need fewer apache child processes, which reduces memory pressure and to some=20 extent competition for CPU resources. An alternative variation on this strategy is to use a reverse proxy -- varnish is purpose designed for this, but you could also use squid in this role -- the idea being that static content can be served mostly out of the proxy cache and it's only the expensive to compute dynamic content that always gets passed all the way back to the origin server. You can also see the same strategy commonly used on Java based sites, with Apache being the small-and-lightning-fast component, shielding a larger and slower instance of Tomcat from the rapacious demands of=20 the Internet surfing public. Cheers, Matthew [1] Setting 'index index.php' in nginx.conf means it will DTRT with directory URLs too. --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig330E7118D7B77CAC47E7C33E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkGKAYACgkQ8Mjk52CukIxEhwCeJS09/JBZXfB4xQk1qs3Bo9AE MT0An1+nloV63x7tq2GCOlufkLCO7aUF =H8lU -----END PGP SIGNATURE----- --------------enig330E7118D7B77CAC47E7C33E--