:> Using two -current machines, both dated 7/16 I got the following
:> message in my log file, which I think explains the weird spontaneous
:> reboots I've been getting.
:>
:> /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
:
:...
:
: I've increased the PMAP_SHPGPERPROC setting in the kernel config
:file to 400 and recompiled just in case the system panics again, however
:with it set to 300 as it is now it recovers ok. Once again, any thoughts
:or suggestions welcome.
:
:Thanks,
:
:Doug
Very weird. The system should definitely not be spontaniously rebooting
due to this, at least not without generating a panic message. The
pmap_collect message is just a warning.
I'm not sure what could be causing the pageout daemon overhead. It
sounds like it ought to be the pmap_collect() function (i386/i386/pmap.c)
but the only way we could tell for sure would be for you to compile up
a profiled kernel which you may not want to do on a production system.
The failure case for the pmap stuff occurs when you have a lot of
processes sharing a lot of data, usually via mmap, where the dataset
fits in memory. Thus the system would run out of pv entries before
running out of physical memory.
In regards to your CGI execution: One thing to look out for is what is
called a cascade failure. This can be a problem on web servers running
CGI's. The problem occurs when a large number of CGI's are run
simultaniously and slow the system down enough that new CGI's are being
forked faster then existing CGI's can complete.
The solution to this sort of problem is to limit the number of
simultanious executions of a particular CGI by using, for example,
SysV semaphores within the CGI or implementing the limit within the
web server. Note that you do not want to cause one type of CGI to be
blocked because too many of another type is running. This sort of limit
is best implemented on a per-CGI-binary basis.
Whatever you do, make sure the web server limits the maximum number of
CGI's that can be running simultaniously to some number that you know
the machine can handle to prevent the machine from crashing due to this
sort of cascade failure.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
