Date: Fri, 12 May 2006 21:28:09 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Iasen Kostov <tbyte@otel.net> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Heavy system load by pagedaemon Message-ID: <20060512112809.GD714@turion.vk2pj.dyndns.org> In-Reply-To: <1147428461.98918.10.camel@DraGoN.OTEL.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
--
Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060512112809.GD714>