Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.

[Evren Yurtesen]

Jeremy Chadwick wrote:
> On Wed, May 14, 2008 at 11:39:10PM +0300, Evren Yurtesen wrote:
>> Approaching the limit on PV entries, consider increasing either the 
>> vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
>> Approaching the limit on PV entries, consider increasing either the 
>> vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
> 
> I've seen this message on one of our i386 RELENG_7 boxes, which has a
> medium load (webserver with PHP) and 2GB RAM.  Our counters, for
> comparison:
> 
> vm.pmap.pmap_collect_active: 0
> vm.pmap.pmap_collect_inactive: 0
> vm.pmap.pv_entry_spare: 7991
> vm.pmap.pv_entry_allocs: 807863761
> vm.pmap.pv_entry_frees: 807708792
> vm.pmap.pc_chunk_tryfail: 0
> vm.pmap.pc_chunk_frees: 2580082
> vm.pmap.pc_chunk_allocs: 2580567
> vm.pmap.pc_chunk_count: 485
> vm.pmap.pv_entry_count: 154969
> vm.pmap.shpgperproc: 200
> vm.pmap.pv_entry_max: 1745520
> 

I guess one good question is, how can one see the number of PV entries used by a 
process? shouldnt these appear in the output of ipcs -a command?

Another good question is, in many places there is references to rebooting after 
putting a new vm.pmap.shpgperproc value to loader.conf. However I just changed 
this on a running system, has it really been changed or was I suppose to reboot?

In either case, I already increased vm.pmap.shpgperproc to 2000 (from 200) and 
still the error occurs, there is not so much load on this box, maybe there is a 
leak somewhere?

Thanks,
Evren