17.02.2013 01:25, Alan Cox wrote: > Regardless of what that web site says, this is not really a race condition. > Instead, you're exhausting a resource in the kernel because of the > characteristics of your workload. The kernel tries to handle this > gracefully, but in extreme cases, the kernel can't keep up with the demand. > Have you simply tried doing as the panic message suggests, i.e., increase > vm.pmap.shpgperproc? Alternatively, you can increase vm.pmap.pv_entry_max to > more directly accomplish the same. > > That said, if possible, you should do as Adrian suggests and change your > Squid configuration to not use 500 helper processes. That will allow a lot > more of your machine's physical memory to go to caching data rather > bookkeeping data structures in the kernel.
A warning in src/sys/i386/conf/NOTES scares me: # # Set the number of PV entries per process. Increasing this can # stop panics related to heavy use of shared memory. However, that can # (combined with large amounts of physical memory) cause panics at # boot time due the kernel running out of VM space. # # If you're tweaking this, you might also want to increase the sysctls # "vm.v_free_min", "vm.v_free_reserved", and "vm.v_free_target". # # The value below is the one more than the default. # options PMAP_SHPGPERPROC=201 I guess, my 4G physical RAM is "large amount" for i386 so I'm afraid of remote server's kernel panic at boot time as I have no idea how exaclty should I increase value of vm.pmap.shpgperproc? What should be an increment? Using concurrency extension means moving from squid-3.1 to squid-3.2, I might try that too, thanks. I was not aware of this new feature in 3.2 Eugene Grosbein _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
