collecting pv entries -- suggest increasing PMAP_SHPGPERPROC

[Matthew Seaman]

Francis Dubé wrote:
> Hi everyone,
> 
> I'm running a a webserver on FreeBSD (6.2-RELEASE-p6) and I have this 
> error in my logs :
> 
> collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
> 
> I've read that this is mainly caused by Apache spawning too many 
> processes. Everyone seems to suggest to decrease the MaxClients 
> directive in Apache(set to 450 at the moment), but here's the 
> problem...i need to increase it ! During peaks all the processes are in 
> use, we even have little drops sometime because there isn't enough 
> 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 ?
> 
> Here's the useful part of my conf :
> 
> Apache/2.2.4, compiled with prefork mpm.
> httpd.conf :
> [...]
> <IfModule mpm_prefork_module>
>    ServerLimit         450
>    StartServers          5
>    MinSpareServers       5
>    MaxSpareServers      10
>    MaxClients          450
>    MaxRequestsPerChild   0
> </IfModule>
> 
> 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 
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 
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 
instance of apache with almost all of the loadable modules and other 
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 content (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 
it's time doing the heavy lifting it's optimised for, and doesn't get distracted by all the little itty-bitty requests.  So you need fewer
apache child processes, which reduces memory pressure and to some 
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 
the Internet surfing public.

	Cheers,

	Matthew

[1] Setting 'index index.php' in nginx.conf means it will DTRT with
    directory URLs too.

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20081027/492490d4/signature.pgp