From owner-freebsd-current Fri Jul 23 16:35:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5C9FE15799 for ; Fri, 23 Jul 1999 16:35:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA28303; Fri, 23 Jul 1999 16:34:59 -0700 (PDT) (envelope-from dillon) Date: Fri, 23 Jul 1999 16:34:59 -0700 (PDT) From: Matthew Dillon Message-Id: <199907232334.QAA28303@apollo.backplane.com> To: Doug Cc: freebsd-current@FreeBSD.ORG Subject: Re: PMAP_SHPGPERPROC: related to pagedaemon? References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message