Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Mar 2003 16:02:19 +0300 (MSK)
From:      Igor Sysoev <is@rambler-co.ru>
To:        Andrew Kinney <andykinney@advantagecom.net>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: shared mem and panics when out of PV Entries
Message-ID:  <Pine.BSF.4.21.0303241557420.40788-100000@is>
In-Reply-To: <3E7E660C.10419.ECBF5C7@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Mar 2003, Andrew Kinney wrote:

> The source of the PV Entry usage is shared memory in Apache 
> (PHP and/or mod_perl).  We know it's Apache memory sharing 
> that causes the problem because nearly all PV Entries are freed 
> when Apache is stopped and the problem is worst right after 
> Apache starts when you have a lot of "clean" memory segments 
> getting shared (10 to 11 million PV Entries used).  After Apache 
> has run for awhile and the shared memory segments become 
> unshared due to them being "dirtied", the number of PV Entries 
> used declines and settles in at a much lower number (3 to 5 million 
> PV Entries used most days).  Apache on this machine likes to 
> hover right around 256 children processes, so you could see how 
> requiring duplicate PV Entries per shared memory segment per 
> Apache process could add up quite quickly.
> 
> Under ideal circumstances, we'd correct our PHP/PERL code to 
> avoid running into the issue at all, but this is customer code that 
> we don't have much control over since we allow users to select and 
> run their own CGI scripts without our intervention.  So, for this 
> instance, we have to solve it at the system level by bullet-proofing 
> our system as much as possible.

How many Apache processes do you have and what's their size ?

> I've read that setting sysctl kern.ipc.shm_use_phys to "1" will 
> cause shared memory segments not to use PV Entries at all.  
> (See 
> http://www.geocrawler.com/archives/3/159/2002/6/50/9031353/ )  
> However, in the real world with FreeBSD 4.7, setting 
> kern.ipc.shm_use_phys to "1" seems to have no visible effect on 
> the number of PV Entries consumed by Apache memory sharing.  
> We're currently running sysctl kern.ipc.shm_use_phys=1 and are 
> still seeing the heavy PV Entry usage after rebooting (sysctl set on 
> boot) with no apparent difference in usage.
> 
> My thoughts at this point are leaning towards setting some limits 
> on shared memory (kern.ipc.shmmax, kern.ipc.shmseg, 
> kern.ipc.shmall, and kern.ipc.shmmax sysctl's) to limit the number 
> of PV Entries that Apache can consume by way of shared 
> memory.  Is that a viable approach to this problem?  What kind of 
> gotchas and caveats should I watch out for in taking this approach? 
>  Any recommendations on which one to tweak first?

kern.ipc.shm_use_phys, kern.ipc.shmmax, etc are for System V shared memory.
They have no relation to the memory that shared between processes via fork().


Igor Sysoev
http://sysoev.ru/en/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0303241557420.40788-100000>