Hi, I checking yesterday's SAR logs for one of our servers and it was showing that utilisation was down to 0% for 10 minutes at 2am. We're unaware of any jobs running at this time so need to find out which process caused this spike.
Is there anything built into SAR (or does anything else exist) that allows you to see what processes where historically running at certain times of the day?
I recommend that you install a free monitoring package that (1) stores performance data in an open source database, (2) has excellent charting / visualization capabilities, (3) works well out-of-the-box and (4) is easily extended.
For this site, we use Zabbix to monitor and troubleshoot performance issues.
On that theme.
If this was a one-off the process(es) will only be found directly if there was process monitoring software already in place or the process itself left a trail (e.g. in cron log or other logs).
If the load happens daily at the same time, running a suitable "ps" to a file from cron during the appropriate period at say 2-minute intervals should help find the process.
If you assume it is a "one off" then you don't need anyrthing, LOL. As you can imagine, we get a lot of "one offs" here, , mostly due to network anomalies. We have a lot of cron jobs running. We don't use ps for troubleshooting much now, but used to before installing zabbix.
I too have large scale server monitoring software, but this is the UFD Q&A and we're trying to address the specific question.
I agree that a totally one-off peak may just cause us to prepare for next time.
Maybe "sar -d" shows unusual disc activity?
Hi, thanks for the replies. No as far as we know there was nothing running on the box at that time (although obviously something was)
Unfortunately I can't install any monitoring software on these boxes as there are very strict rules about what software can and can't be ran on these boxes, so unless it's something that is part of the standard Solaris 10 install then I won't have that tool available to me.
As Neo says, I may just have to write this off as a one-off (it hasn't happened since) and then maybe knock up a monitoring script if it occurs again.