Skip site navigation (1)Skip section navigation (2)
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>