[rhelv6-list] sar

Cale Fairchild cfairchild at brocku.ca
Wed Mar 5 16:21:19 UTC 2014


Yes, but if the old files are kept for a month then they will wrap.

I just restored the /var/log/sa?? files from a backup from a month ago 
and when you compare the results from running sar on the current file 
(/var/log/sa/sa05) and the restored file (in my case 
/mnt/restored/var/log/sa/sa05) I found that the first set of times 
(12:00:01AM - 11:50:01PM) are identical to the result from the back 
file, then today's results are listed starting again at 12:00:01AM.

So if they are not deleted within the month (managed by the HISTORY 
setting) each month the sysstat values will just be added to the 
previous months statistics and eventually I found that the files got 
corrupt (his is what started me looking into it). And since the cron job 
is just run once every 10 minutes, and not done by a daemon, there 
really is no other option than appending to the file or you would just 
get the most recent data point recorded.

Oddly, if you read the comments in /etc/sysconfig/sysstat it implies 
that instead of wrapping the program is supposed to use a sub-directory 
structure if HISTORY is greater than a month so perhaps this error will 
only occur between the values of 28 and 31. But I have not had time to 
test that.

Cale

On 05/03/2014 10:18, Feldt, Andrew N. wrote:
> Note that HISTORY only affects how many old files are kept.  The real issue is that a single existing file now has two entries in it for each time.  To demonstrate this and keep it simple, choose a single statistic and search for what should be a single record (within one second).  For example, for a file after March 1,
>
> # sar -n NFSD -f /var/log/sa/sa02 | egrep '^12:10:0. AM'
> 12:10:01 AM      1.95      0.00      1.95      0.00      1.95      0.00      0.00      0.00      0.00      0.00      1.59
> 12:10:01 AM      2.54      0.00      2.54      0.00      2.54      0.00      0.00      0.00      0.00      0.09      2.03
>
> gives two records while for a date before March 1 (Feb 28) yields:
>
> # sar -n NFSD -f /var/log/sa/sa28 | egrep '^12:10:0. AM'
> 12:10:01 AM      2.76      0.00      2.76      0.00      2.76      0.00      0.00      0.00      0.00      0.00      2.38
>
> just one record.  Note also that this is not the data from the day before being appended to.  For example:
>
> sar -n NFSD -f /var/log/sa/sa03 | egrep '^12:10:0. AM'
> 12:10:01 AM      2.19      0.00      2.19      0.00      2.19      0.00      0.00      0.00      0.00      0.04      1.83
> 12:10:01 AM      2.47      0.00      2.47      0.00      2.47      0.00      0.00      0.00      0.00      0.00      2.05
>
> which is the day after my first example above and does not have either entry correspond to either of the other entries.
>
> I begin to suspect that two instances of sadc are being run somehow.
>
> Andy
>
> Andy Feldt
> Senior System Support Programmer
> Affiliate Assistant Professor
> Homer L. Dodge Department of Physics & Astronomy
> The University of Oklahoma
>
> On Mar 5, 2014, at 6:17 AM, Cale Fairchild <cfairchild at brocku.ca> wrote:
>
>> I looked at the systems this morning and it keeps HISTORY + 1 (the current day) files active so if the preceding month has 28 days it will not clear the old months logs. Strangely I had one system set to 26 and one to 27 and it seems that even the server with 27 days was still wrapping so there might even be something to do with timing around 00:00 that needs an additional extra day of clearance tacked on to it. This may constitute a bug as it is not mentioned in the man pages as expected behaviour. The issue about using 28 days I think was just a misunderstanding of how the program handles the log rotation.
>>
>> Cale
>>
>> On 05/03/2014 04:41, Iain Morrison wrote:
>>> Hi Cale,
>>>    thanks. That explains why things started going weird after Feb.
>>>
>>> yours
>>>
>>> iain
>>>
>>>
>>> --
>>>   Iain Morrison
>>> IT Manager
>>> MRC Epidemiology Unit
>>> Institute of Metabolic Science
>>> Box 285
>>> Addenbrooke's Hospital
>>> Hills Road
>>> Cambridge
>>> CB2 0QQ
>>> Tel 01223 769200
>>>
>>> -----Original Message-----
>>> From: rhelv6-list-bounces at redhat.com
>>> [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Cale Fairchild
>>> Sent: 05 March 2014 02:29
>>> To: rhelv6-list at redhat.com
>>> Subject: Re: [rhelv6-list] sar
>>>
>>>     From what I can see, it appears that in the last release of sysstat
>>> (sysstat-9.0.4-22.el6) they changed the values in /etc/sysconfig/sysstat
>>>
>>> which direct how much history is kept in /var/log/sa. The main issues
>>> appears to be that they changed HISTORY=7 to HISTORY=28 which should
>>> theoretically work on most months but seems to have wrapped around even
>>> in January which should not have been the case as at least the sa1-sa3
>>> should have disappeared.
>>>
>>> Cale Fairchild
>>>
>> _______________________________________________
>> rhelv6-list mailing list
>> rhelv6-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rhelv6-list
>
> _______________________________________________
> rhelv6-list mailing list
> rhelv6-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rhelv6-list




More information about the rhelv6-list mailing list