Re: kernel: Approaching the limit on PV entries...
On 10/10/08, Mark Tinguely [EMAIL PROTECTED] wrote: vm.pmap.pv_entry_count: 583006 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 2243305 The system: FreeBSD 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Wed Oct 1 07:51:58 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Can someone briefly explain what this is telling me and how to decide which sysctl to increase? I have found some old postings that predate the sysctls that suggested increasing shpgperproc in the kernel configuration, about 50 at a time until the problem goes away, but I still have no clue what that is accomplishing. what (simplified): the pv_entry helps the virtual memory system track physical pages, so a physical page can be shared with another process or another virtual address. In the i386/amd64 the pv_entry entries are allocated in page size chunks on a per process memory map basis. This helps reduce redundant pointers and overall saves memory. shpgperproc can be read as the number of shared pages per proceess. pv_entry_max is calculated from shpgperproc (and on the amd64, shpgperproc can be derived from setting the vm.pmap.pv_entry_max). On the amd64, the values can be adjusted by sysctl, but on the i386 the values must be compiled into the kernel. There are some automatic adjustments in the calculation of the number of pv_entry, but the warnings are given early enough to help aid in the tweaking of the value. The advice of slowly increasing vm.pmap.shpgperproc is probably the best solution. I would adjust up slower than 50 (25% increase seems to be pretty high). --Mark Tinguely. Thanks. I'll see what happens. In amd64/7.0 is there any chance running out of pv_entrys would show up as failures in interprocess communication rather than a panic? The original symptom was that certain web pages (or jailed servers, I'm not sure) were unreachable, as if the firewall were misconfigured, until the system was rebooted. I didn't get to look at the system before it was rebooted, and I find very little in the logs to explain what was going on. Thanks again, - Bob [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: Approaching the limit on PV entries...
Thanks. I'll see what happens. In amd64/7.0 is there any chance running out of pv_entrys would show up as failures in interprocess communication rather than a panic? The original symptom was that certain web pages (or jailed servers, I'm not sure) were unreachable, as if the firewall were misconfigured, until the system was rebooted. I didn't get to look at the system before it was rebooted, and I find very little in the logs to explain what was going on. Sometimes pv_entry allocation can fail even below the pv_entry_high_water if there is no more free pages available to allocate for a pv_entry chunk. Operations (such temp mappings, copies) will not occur if the pv_entry_high_water (90% if pv_entry_max) has been reached OR a page is not immediately available for allocation. The first situation is quiet, you could put a sysctl counter. Maybe PV_STAT(pc_chunk_tryfail++) should be moved from get_pv_entry() to the else case of the routine pmap_try_insert_pv_entry(). On the other hand, some allocations (permanent mapping) are unconditional and can occur even when pv_entry_max has been exceeded (amd64). The code will also wait for page allocations. --Mark Tinguely. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: Approaching the limit on PV entries...
Bob Johnson wrote: A web server with several jailed copies of Apache is having problems that seem to be caused by incorrect IPFW rules, but in the process of working on that, I find in the log the following repeated many times: Oct 8 23:29:50 spider kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. Oct 8 23:30:52 spider kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. sysctl gives me: # sysctl vm.pmap vm.pmap.pmap_collect_active: 0 vm.pmap.pmap_collect_inactive: 0 vm.pmap.pv_entry_spare: 45818 vm.pmap.pv_entry_allocs: 595716945 vm.pmap.pv_entry_frees: 595133939 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pc_chunk_frees: 3543052 vm.pmap.pc_chunk_allocs: 3546795 vm.pmap.pc_chunk_count: 3743 vm.pmap.pv_entry_count: 583006 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 2243305 The system: FreeBSD 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Wed Oct 1 07:51:58 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Can someone briefly explain what this is telling me and how to decide which sysctl to increase? I have found some old postings that predate the sysctls that suggested increasing shpgperproc in the kernel configuration, about 50 at a time until the problem goes away, but I still have no clue what that is accomplishing. Also, the system has been rebooted since I collected those messages, and they aren't happening any more, but I expect they will reappear eventually. Until then I probably can't actually test anything. Thanks for your time, -- Bob Johnson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] For what it's worth, I just came across a machine with the same exact problem, except when I do finally run out of entries, I get a kernel panic. FBSD 7-RELEASE-p4 ~Paul ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: Approaching the limit on PV entries...
vm.pmap.pv_entry_count: 583006 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 2243305 The system: FreeBSD 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Wed Oct 1 07:51:58 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Can someone briefly explain what this is telling me and how to decide which sysctl to increase? I have found some old postings that predate the sysctls that suggested increasing shpgperproc in the kernel configuration, about 50 at a time until the problem goes away, but I still have no clue what that is accomplishing. what (simplified): the pv_entry helps the virtual memory system track physical pages, so a physical page can be shared with another process or another virtual address. In the i386/amd64 the pv_entry entries are allocated in page size chunks on a per process memory map basis. This helps reduce redundant pointers and overall saves memory. shpgperproc can be read as the number of shared pages per proceess. pv_entry_max is calculated from shpgperproc (and on the amd64, shpgperproc can be derived from setting the vm.pmap.pv_entry_max). On the amd64, the values can be adjusted by sysctl, but on the i386 the values must be compiled into the kernel. There are some automatic adjustments in the calculation of the number of pv_entry, but the warnings are given early enough to help aid in the tweaking of the value. The advice of slowly increasing vm.pmap.shpgperproc is probably the best solution. I would adjust up slower than 50 (25% increase seems to be pretty high). --Mark Tinguely. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
