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