Date: Fri, 12 May 2006 15:31:01 +0300 From: Iasen Kostov <tbyte@otel.net> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Heavy system load by pagedaemon Message-ID: <1147437061.98918.24.camel@DraGoN.OTEL.net> In-Reply-To: <20060512112809.GD714@turion.vk2pj.dyndns.org> References: <1147264089.51661.10.camel@DraGoN.OTEL.net> <1147264379.51661.14.camel@DraGoN.OTEL.net> <1147265038.51661.19.camel@DraGoN.OTEL.net> <1147361590.33341.19.camel@DraGoN.OTEL.net> <20060512071711.GA714@turion.vk2pj.dyndns.org> <1147428461.98918.10.camel@DraGoN.OTEL.net> <20060512112809.GD714@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2006-05-12 at 21:28 +1000, Peter Jeremy wrote: > On Fri, 2006-May-12 13:07:41 +0300, Iasen Kostov wrote: > >On Fri, 2006-05-12 at 17:17 +1000, Peter Jeremy wrote: > >> 'page daemon wakeups' counts the number of times that the pagedaemon > >> is woken up due to a page shortage. > > I think I was not correct here. It looks like the pagedaemon can be > woken up (via vm_pages_needed) even if vm_pages_needed is still zero. > > >> How about posting a complete 'vmstat -s'. > > I spoke too soon. The relevant counters are in vm.stats.vm.* and not > reported by vmstat. > > >But there is something else: > >"collecting pv entries -- suggest increasing PMAP_SHPGPERPROC" x 5 times > >(which is it maximum number of this warrnings). > > The call tree for this is > vm_pageout() with wakeup(&vm_pages_needed) && vm_pages_needed == 0 > vm_pageout_scan() > vm_pageout_pmap_collect() with pmap_pagedaemon_waken non-zero. > > vm_pageout_pmap_collect() runs with Giant held and, based on a very > brief check, looks quite expensive. > > >When I checked sysctl vm.zone I saw "PV ENTRY" going near to it's > >maximum right before the lock happen and then after the lock by > >pagedaemon it go down to ~1000 > > You mentioned eaccelerator and having lots of users and httpd. I > suspect the comment in NOTES is relevant for you and you need to > increase PMAP_SHPGPERPROC as recommended: > > # 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 Exactly what i did :). I set vm.pmap.shpgperproc=600 in loader.conf and about 5 min after boot the system paniced and I was not able even to see the message (either because I was pressing enter for the command or it just doesn't wait for a key). Then i set it to 500 in loader at boot time and currently it works but when it crashed used PV entries were ~4 300 000 now they go to ~5 000 000 and it doesn't panic. Which make me think that the panic is not related to setting vm.pmap.shpgperproc to 600 (which could probably lead to KVA exhastion) but to something else. I'll try to increase KVA_PAGES (why isn't there tunable ?) and then set vm.pmap.shpgperproc to some higher value, but this will be after a fresh make world (I cvsuped already :( ) some time soon.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1147437061.98918.24.camel>