Subject: Re: [vserver] which guest hit the memory limit?
From: Ed W <lists@wildgooses.com>
Date: Thu, 06 Aug 2009 18:02:37 +0100
Thu, 06 Aug 2009 18:02:37 +0100
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...

Good luck

Ed W


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...

Good luck

Ed W