Usage spike on my server
I wasn't expecting much activity on it, it should be sitting idle. As a newbie Linux admin I'm not sure whether or not I should be worried or how to go about investigating. Not sure which log files to look at, or even any tricks for figuring out WHERE to look in a log file. I have no idea how to start dealing with this, but I'm eager to learn. Could anyone point me in the right direction?
Here are some usage graphs:
~~![](<URL url=)http://imgur.com/W8lb8VMl.png
![](~~
4 Replies
As for logs, which log files to look at depends on which distro you are using. You'll want to look in the log files during the time indicated in the graphs as well as before hand (maybe an hours worth).
@rfeliciano:
Are you using Longview? If so, you can simply scroll back to when this happened and take a look at the processes list to see which process caused the problem.
As for logs, which log files to look at depends on which distro you are using. You'll want to look in the log files during the time indicated in the graphs as well as before hand (maybe an hours worth).
Didn't have Longview set up, am doing that now. As for the logs, I'm using Debian 8, there are many in /var/logs, not sure where to look?
On a related note, does anyone know why some of my logs end in .1 .2, etc..?
@ericwaldman:
On a related note, does anyone know why some of my logs end in .1 .2, etc..?
.1, .2, etc means they've been rolled over by logrotate.
Notice that the network usage graphs you posted are in bits/sec. A spike up to 700 b/sec is negligible.
Check cron to see if you have some job scheduled. Perhaps you have and apt-get update scheduled or something of that sort?
> .1, .2, etc means they've been rolled over by logrotate.
Ah cool
@glg:
Check cron to see if you have some job scheduled. Perhaps you have and apt-get update scheduled or something of that sort?
I have the following cron jobs set up: apt, aptitude, dpkg, logrotate, man-db, mlocate, sendmail, bsdmainutils, exim4-base and 0anacron
All the apt, aptitude and dpkg jobs seem to do is back up a cache of some sort. Haven't had the chance to look into the other ones but if anyone else's experience can point out a likely suspect for the 500% cpu usage it would be a great help
You guys are being super helpful, thanks so much