Date: Fri, 12 May 2006 13:07:41 +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: <1147428461.98918.10.camel@DraGoN.OTEL.net> In-Reply-To: <20060512071711.GA714@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2006-05-12 at 17:17 +1000, Peter Jeremy wrote:
> On Thu, 2006-May-11 18:33:10 +0300, Iasen Kostov wrote:
> > And another odd thing (to me atleast):
> >
> >#:> vmstat -s | grep "daemon\|fault"
> > 0 page daemon wakeups
> > 0 pages examined by the page daemon
> > 4992608 copy-on-write faults
> > 29021 copy-on-write optimized faults
> > 75167 intransit blocking page faults
> > 66956262 total VM faults taken
> > 0 pages freed by daemon
> >
> >Acording to vmstat pagedaemon has never been awake.
>
> 'page daemon wakeups' counts the number of times that the pagedaemon
> is woken up due to a page shortage. It does not include the 5-sec
> wakeups.
>
> How about posting a complete 'vmstat -s'. A look at the code suggests
> that vm_pageout_page_stats() thinks there's a page shortage (since
> that's the only piece of code that will actually do anything if page
> daemon wakeups is zero).
#:> vmstat -s
38479689 cpu context switches
8311921 device interrupts
2247328 software interrupts
77805675 traps
352344722 system calls
41 kernel threads created
16904 fork() calls
1827 vfork() calls
0 rfork() calls
0 swap pager pageins
0 swap pager pages paged in
0 swap pager pageouts
0 swap pager pages paged out
32095 vnode pager pageins
152280 vnode pager pages paged in
549 vnode pager pageouts
549 vnode pager pages paged out
0 page daemon wakeups
0 pages examined by the page daemon
51939 pages reactivated
5311477 copy-on-write faults
11437 copy-on-write optimized faults
25579287 zero fill pages zeroed
25490864 zero fill pages prezeroed
39320 intransit blocking page faults
74643308 total VM faults taken
0 pages affected by kernel thread creation
71254993 pages affected by fork()
8872256 pages affected by vfork()
0 pages affected by rfork()
48455025 pages freed
0 pages freed by daemon
12139663 pages freed by exiting processes
261655 pages active
346637 pages inactive
39970 pages in VM cache
108891 pages wired down
1236812 pages free
4096 bytes per page
236461588 total name lookups
cache hits (97% pos + 2% neg) system 0% per-directory
deletions 0%, falsehits 0%, toolong 0%
But there is something else:
"collecting pv entries -- suggest increasing PMAP_SHPGPERPROC" x 5 times
(which is it maximum number of this warrnings).
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 ... and I saw this after a crash which
could explain alot of things. Most probably the lock occurs when this
collecting of pv entrys happen and this could lead to a crash (which is
inherited from 4.x series as I saw mails about that from 2003 and 4.7).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1147428461.98918.10.camel>