Subject: Re: [vserver] which guest hit the memory limit?
From: "Michael S. Zick" <mszick@morethan.org>
Date: Thu, 6 Aug 2009 12:08:17 -0500

On Thu August 6 2009, Ed W wrote:
> Edward Capriolo wrote:
> > On Thu, Aug 6, 2009 at 12:25 PM, Ed W<lists@wildgooses.com> wrote:
> >   
> >> Edward Capriolo wrote:
> >>     
> >>> I can make a use case for always wanting a reset as a user feature.
> >>>
> >>> Enter busy NFS servers. I want to be able to graph clients and servers
> >>> to see, who is using the most NFS ops. Enter a 32 bit OS level
> >>> counter, a counter that has been 32 bit for over 6 years of bug
> >>> reporting.
> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=103682&cat=bin
> >>>
> >>> Eventually you hit a wrap around condition (this may not be the case
> >>> with vserver). The only way to fix it is restart/reboot.
> >>>
> >>> That stinks! because you spend half your life bragging about high *nux
> >>> uptime but then you need to reboot/restart for your counters, and you
> >>> lose your bragging rights. With a 64 bit counter needed a reset is
> >>> unlikely, but if they are 32 bit it does come into play. So yes reset
> >>> is always useful for stat guru's like myself :)
> >>>
> >>>       
> >>
> >> ksplice...
> >>
> >>
> >>     
> >
> > Looks nice, so what is ksplice going to do for a vserver counter. Will
> > updating the kernel reset it? Can i reset the counter without an
> > update? Also look up the kernel and bug in question is a 32/64 bit NFS
> > counter FreeBSD bug.
> >
> > Just being able to reset the vserver counters from user space is a nice feature.
> >   
> 
> Yeah, posted without reading too carefully. 
> 
> My smart arse comment was more about being able to fix the counter 
> without rebooting and less about being able to reset the counter...
> 

It should be a kernel data resident counter -
Look it up in /proc/kmem an poke a zero into it.  ;)

Mike
> Good luck
> 
> Ed W
>