This will run the sar command with the -q flag that shows load averages.

The 5 tells it to run a check every 5 seconds, and the 12 tells it to do it 12 times.

If your ldavg-1 column stays consistently high, or continues to rise during this load check, this is an indication that you could have something on the server spiking its usage.

Now we noticed from looking at our load averages that at 2:10:11 PM the load was 1.29, and it continued to spike up till 02:10:31 PM where the load got as high as 1.73.

It's very common that websites being accessed, and having to run PHP scripts, or other server side code can cause these spikes in your usage. So you can check in your Apache access logs for what might have been going on around the time of the spike.

Using the following code we are going to look at our website's access log to see how many "hits" happened from 2:09PM - 2:10PM (14:09 - 14:10). This way we can see the requests leading up to the spike, as well as after:

This right here is already a pretty telling sign, our load average started to spike at 2:10 PM (14:10) and during that minute we had almost double the amount of requests to our site as the previous minute. So it would make sense that the server is having to work harder to serve more requests.

Now comes the part where we take an even deeper look at what was going on with the requests. Because the server can easily handle 100 or so image or plain HTML page requests with less of a usage spike than having to run PHP scripts for instance, it's important to know exactly what is getting requested.

We can use the following command in order to see what duplicate requests have been happening:

15 GET /wp-content/plugins/s2member/s2member-o.php 22 GET /about-us/ 26 GET /wp-content/uploads/2012/06/logo.png

Here we can see that this happens to be a WordPress site, the highest duplicated request is a logo.png image so that's probably not going to cause a load spike. However the 22 requests for /about-us/, and 15 for /wp-content/plugins/s2member/s2member-o.php in a 2 minute period might have.

Taking a look at this WordPress site, I noticed that there is currently no form of caching enabled such as using the W3 Total Cache plugin. As such that means that each time the /about-us/ page is getting requested, the server is going to have to re-process the PHP script, connect to the database, and retreive the page. So here we were able to determine within a few minutes of a server load spike that our possible culprit of that spike was a sudden influx in requests for a WordPress page that isn't cached.

The article is too difficult or too technical to follow.
There is a step or detail missing from the instructions.
The information is incorrect or out-of-date.
It does not resolve the question/problem I have.

How did you find this article?

Please tell us how we can improve this article:

Email Address

Name

new! - Enter your name and email address above and we will post your feedback in the comments on this page!