It is very common, despite affordable hardware, to have server load problems. There can be various reasons for a high load on the server, such as inadequate RAM / CPU, slower hard drives, or simply not optimized software. This article will help you identify what the bottleneck is and where you should invest. However, do not take it as a replacement for professional advice / service. You should always seek a professional service if you can afford the associated costs.
I) First of all, are you really in trouble?
Usually people look up the upload in control panels, using the “uptime” or “top” command. You can probably run the “uptime” command in your root shell to find out what the load is, but I’d like you to use “top” for now (quite a bit please). This will help you identify how many CPUs are being reported *. You should be able to see something like cpu00, cpu01, etc.
A load of ~ 1 per CPU is reasonable. For example, it is fine if the load is 3.50 and you have 4 CPUs.
Another thing to consider when looking at load through uptime or top is to understand what it shows. For example: (on a 2HT cpus server, reported as 4)
18:30:55 to 17 days, 5:17, 2 users, average upload: 4.76, 2.97, 2.62
The first part (3.76) shows the average load in the last 5 minutes, while the second (2.97) and the third (2.62) show averages of 10 and 15 minutes respectively. It’s probably a peak here that I wouldn’t be overly concerned about (a little carefree?), But if you are, read on!
Are you quite happy with how you were able to identify that your server is really overloaded? Sorry to hear that, but you never know because sometimes servers can handle a lot more load than shown. Load averages aren’t that accurate after all and can’t always be the final deciding factor. Confused? It was just technical information that you don’t need to worry so much about. Go ahead if your loads are something to worry about.
* note the use of the term “informed”. I have used this term because a P4 CPU with HT technology will be reported as 2 even if it knows that your server has a CPU.
II) Where is the problem?
To identify the problem, you have to run a series of logic tests (Ok, not as scary as it may sound). All you need is some free time, probably 30 to 45 minutes, and root access to your server (don’t expect magic;)). Ready to start? Let’s go!
Note: Run the checks several times to come to a good conclusion.
1. Check the RAM (the most common bottleneck!).
# free -m
The output should look something like this:
# free -m
total cached used free shared buffers
Mem: 1963 1912 50 0 28 906
– / + buffers / cache: 978985
Trade-in: 1027157869
Any reaction like, “Oh gosh, most of the RAM is depleted.” Do not panic. Take a look at the buffers / cache that says “985” mb of RAM is still free in buffers. As long as you have enough memory in the buffers and your server doesn’t use a lot of swapping, you’re fine with RAM. Your server starts using SWAP (as does Pagefile), which is part of your disk mapped as memory, but is comparatively very slow and can slow down your system even more if you have a busy hard drive (which I doubt it wouldn’t if you’re using so much RAM). In short, at least 175MB available in buffers and no more than 200MB swapped.
If RAM is the problem, you should probably look for optimizations in your PHP / Perl scripts, MySQL + server and Apache queries.
2. Check if I / O (input / output) usage is excessive
If there are too many read / write requests on a single hard drive, it will slow down and you will have to upgrade to a faster drive (with more RPM and cache). The alternative to a faster single drive is to split the load across multiple drives by spreading most of the requested content across multiple drives, which can easily be achieved by using “symbolic links” (soft links to files / folders). To identify, if your I / O problem is causing your server to lag:
#top
Read the result in the “iowait” section, for each CPU. In ideal situations, it should be close to 0%. However, if you are examining at the time of a peak load, consider rechecking these values several times to come to a good conclusion. Anything greater than 15% is worrying. You can then check your hard drive speed to see if it really is lagging:
If you know that your hard drive exists at / dev / sda or / dev / hda, just do the following. Or run the “df -h” command to check which drive your data resides on.
# hdparm -Tt / dev / sda
The exit:
/ dev / sda:
Time Cached Reads: 1484 MB in 2.01 seconds = 739.00 MB / s
Time buffered disk reads: 62MB in 3.00 seconds = 20.66MB / s
It was amazing at the buffer cache reads, probably due to the onboard disk cache, however the buffered disk reads are only 20.66MB / sec. Anything under 25MB is something you need to worry about.
3. Is all the CPU power being consumed?
#top
Check the top output to find out if you are using too much CPU power. You should look for the idle value next to each CPU entry. Anything below 45% is something you really should be concerned about.
III) Identified problem, what is the solution?
In closing, let me offer some solutions for each problem:
A global solution to all problems is to optimize MySQL and the web server, including PHP / Perl scripts and queries. Or the least you can do is optimize Apache and MySQL server parameters to work better.
1. Too much CPU usage
In “ps -auxf” or “top” look for processes that use too much CPU. If it’s HTTP or MySQL, you’d better optimize your scripts and queries, if possible. In most cases, it is extremely difficult to optimize all scripts and queries and a better option is to simply opt for a CPU change / upgrade. A dual CPU should work better, but the type of upgrade you are looking for depends on your current CPU.
2. RAM is exhausted
It’s like you’re in the same kind of situation as the CPU. Optimize HTTP, MySQL, scripts, etc. or opt for a RAM upgrade. You can install Opcode caching software like APC (from Pear) for PHP to make it work better while decreasing the load.
3. The disk is completely used (hey, I don’t mean the space)
Here you have to opt for a faster disk like SATA over normal IDE or SCSI over SATA. Well, I was just speaking in general. You need to consider factors like RPM and cache to end up looking for a worthwhile upgrade. The second option is to obtain several units of the same class and distribute the load among the units. A common methodology is to serve MySQL from a second drive.
IV.conclusion
Wasn’t that very helpful? My article may have flaws, ahh, excuse me. It’s my first article and this really consumed quite a few brain cells of mine. That’s a bit personal, isn’t it? Let’s get back to the matter.
FYI, in the example the problem was with I / O usage and the hard drive was slowing down.
A guide can never be complete on its own or offer you everything you need to reach the expert level (you have to keep learning to get there). When in doubt, hire experts to review your server. Somehow, if you don’t have the money to spend, you are still safe! You can refer to our server optimization help section for help with optimizing your server.