Date: Sun, 17 Feb 2013 21:17:03 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: alc@freebsd.org Cc: stable@freebsd.org, Alan Cox <alan.l.cox@gmail.com> Subject: Re: i386: vm.pmap kernel local race condition Message-ID: <5120E65F.5080205@grosbein.net> In-Reply-To: <CAJUyCcOHFgGqzvm43y-dojvsXdNydYmfd9rwHMkdjqDyvjJuKQ@mail.gmail.com> References: <511CECCC.60400@grosbein.pp.ru> <CAJUyCcOHFgGqzvm43y-dojvsXdNydYmfd9rwHMkdjqDyvjJuKQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5120E65F.5080205>