sar bug?

[Chet Nichols III]

Hey Tim-
Sorry for the delay- thanks for that! I'll add a note to the bug with my
experiences, and hopefully one of us can get an answer. I'm not sure where
the bug in the kernel would be, since /proc seems to handle rollovers
correctly.

Looking at sar.c (but not too in depth), I'm wondering if it has to do with
rollovers though somewhere. For example (lets used signed ints, even though
I'm not sure what really is used in proc for /proc/net/dev), /proc/net/dev
shows eth0 sending almost 2,147,483,647 bytes (or 32bit signed). As sar goes
through each snapshot, it uses the previous value and the current value to
calculate bytes/sec, but if at any point the value hits 32 bits, the kernel
will reset the value in proc/net/dev to 0, and sar will be subtract large,
almost 32bit number from a number close to 0, returning a huge negative
number.

However, I'm not getting a huge negative number, I'm getting a huge positive
number (and there's no abs() being applied to the result, at least from what
I saw, so that makes me more curious). Also, you'd think that it would only
happen that one and only time the previous was greater than the current..
ie: the next run through, the current bytes sent would be, say 23981, and
the previous would be 10481 or whatever, so it would happen very
infrequently.. but instead, once it starts happening, it doesn't stop.

So.. rollovers? Something to do with possibly casting/converting between
signed/unsigned ints? Just random shots in the dark without really looking
too deeply at anything- but let's hope someone has an answer :D

Talk to you soon, thanks again!

Chet


On Tue, Apr 29, 2008 at 4:37 PM, Tim Mooney <Tim.Mooney at ndsu.edu> wrote:

> In regard to: sar bug?, Chet Nichols III said (at 2:48pm on Apr 29, 2008):
>
>  hey there-
> >
> > anyone ever seen a bug in sar where it will start spitting out incorrect
> > values? we're running on 32bit intels. an example:
> >
> > 06:40:13 PM     IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s
> > txcmp/s  rxmcst/s
> > 06:40:18 PM        lo      0.00      0.00      0.00      0.00      0.00
> > 0.00      0.00
> > 06:40:18 PM      eth0 307775.86 390641.38 66821927.59 460472182.76
> > 0.00      0.00      0.00
> > 06:40:18 PM      eth1      0.00      0.00      0.00      0.00      0.00
> > 0.00      0.00
> > 06:40:18 PM      sit0      0.00      0.00      0.00      0.00      0.00
> > 0.00      0.00
> >
>
> That's funny, I was just going to send an email to the list about a
> similar issue.  I opened a bug about it:
>
>        https://bugzilla.redhat.com/show_bug.cgi?id=443190
>
> The problem for us is that we're not running the stock kernel, so I don't
> think Red Hat is going to be too sympathetic.  Are you using the stock
> kernel?  If so, maybe you want to add your name to that bug.
>
> Our main complaint is with the disk I/O statistics -- I modified the
> sysstat
> cron job to also save disk statistics, and sar frequently reports spurious
> values when reporting on the collected sa data.  This happens even using
> iostat interactively, though, so it's not just the data that's recorded
> by sadc.
>
> The sysstat FAQ says it's a kernel bug, but I'm puzzled why it's been
> allowed to persist for so long, if it's a known kernel bug.
>
> Tim
> --
> Tim Mooney                                        Tim.Mooney at ndsu.edu
> Information Technology Services                   (701) 231-1076 (Voice)
> Room 242-J6, IACC Building                        (701) 231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
> --
> redhat-sysadmin-list mailing list
> redhat-sysadmin-list at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list
>



-- 
/*
Chet Nichols III
mail: chet.nichols at gmail.com
(aim: chet / twitter: chet)
*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/redhat-sysadmin-list/attachments/20080502/2fb043c5/attachment.htm>