For those of you PHP programmers, thinking about to switch to Ruby on Rails because you've been hearing a lot about it lately. It's the latest hype but that's all it is. I agree it's a nice framework with somewhat greater productivity but as far as I was concerned, I never felt comfortable using it due to a totally different syntax and a feeling of imprisonment.

Anyways, not to get personal here, and getting down to the real talk, please head to Security Space's August Apache module usage report

The survey data clearly suggests that PHP is still the king and it will considering the amount of market share it lost (percentage), it's not going down too soon. Back in days of 2000, when PHP was the craze, it had oust perl by great margins in short amount of time but perl still holds an 11% share according to survey. Looking at the current pace of ruby on rails, it doesn't seems like it's the next king. I agree the hype's created but users switching to rails are doing it mostly following the hype and I know quite a many who returned to the good old environment of PHP after switching to rails. It's of no doubt that rails can help you increase productivity by simplifying few tasks, but do many of us programmers like to see kind-of 'computer generated' code? I never liked framework and I rely on libraries that I have written or borrowed from few good sources and never had a productivity degration.

Although ruby on rails is a great framework and pretty awesome for newcomers, you shouldn't give up PHP because you think PHP will die after Rails pick up. The statistics do not suggest anything similar and since PHP's still in very active development, you cannot expect it to die anytime sooner.

All I want to say is, don't switch to another language because other's say it's the 'future of the internet'. Why not research yourself before jumping on to conclusions or simply switching over? Unless you have a real strong reason to switch to another language, you should stick with the one you're familiar and comfortable with.

In my last article, I mentioned that you can decrease I/O usage and hence decrease the load on the server making it run faster, by moving MySQL to a second drive. If your server disk's I/O usage is very high, it's either due to a kernel fault (specificially, 2.6.9-xx kernels) or your disk is being accessed heavily. In such a situation, you should spread the load onto multiple drives.
If your server is using much MySQL, then it would be wise to move MySQL to a second drive. (Provided the second drive isn't busy as well!)

Note: This how to is written with linux in mind although it may work on many other *nix operating systems

I) Do you really need to move MySQL to a second disk?
Please check my last article title "Server overloading explained" and find out if your I/O usage is high. If it is higher than what you may consider normal, then follow on with the how to.

II) Mount point - Where is the second disk mounted?
You need to know where your second disk is mounted (obviously, you aren't throwing your data away in the space, are you?). If you aren't sure about your disk's mount point, then run the following command:

# df -h

It should show you the output which can help you identify the mount point of your disk. Make sure you can differentiate between disks. /dev/hdaX are usually the parititions of the main disk, while /dev/hdb or /dev/hdc are commonly used for secondary drives.

Teaching you how to mount is beyond the scope of this How To. Step to our Server Optimization & Help section to get help with mounting a second disk.

III) Move MySQL data to the second disk!
Now that you have identified your mount point of the second disk, you can move the data over. It should take some time to move data from your main disk to the second disk so make sure you do it at an off-peak time.

a) Stop the MySQL service
# service mysqld stop

b) Move data from your main disk to second disk (please make sure there is no directory named "mysql" in /disk2/ -- Replace /disk2/ with the mount point of your secondary disk)
# mv /var/lib/mysql /disk2/

c) Create a symlink (Replace /disk2/ with the mount point of your secondary disk)
# ln -s /disk2/mysql /var/lib/mysql

d) Restart MySQL now
# service mysqld start

That's it, you're done! If MySQL isn't accessed heavily and instead you want to move some of your very popular content, you can do that in a similar manner. Basically, all you need to do is copy the data over to the second disk and create a symlink from the previous location to the new one.

Author and Copyright
Asad Niazi is currently studying for Bachelors in Computer Sciences with passionate interest in PHP coding and Server Optimization.
Copyright 2006, Asad Niazi & SpiceFuse. May not be republished in any form without permission.

It's very common, despite of the affordable hardware, to have load issues on the server. There can be a number of reasons for high load on the server such as, inadequate RAM/CPU, slower hard disk drives, or just unoptimized software. This article will help you identify what's the bottleneck and where do you need to invest on. Please, however, do not take it as a replacement of professional advice/service. You should always seek professional service if you can afford the costs associated.

I) First of all, are you really in trouble?

Usually people look for load in control panels, using "uptime" or "top" command. You can probably execute the "uptime" command in your root shell to find out what's the load, but I would like you to use "top" for the moment (pretty 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 for each cpu is reasonable. For example, you're fine if the load's 3.50 and you have 4 CPUs.

Another thing to consider while looking at the load via uptime or top, is to understand what it shows. For instance: (on a 2HT cpus server, reported as 4)

18:30:55 up 17 days, 5:17, 2 users, load average: 4.76, 2.97, 2.62

The first part (3.76) shows the load average in the last 5 mins, while the second (2.97) and third (2.62) shows averages of 10 and 15 mins respectively. It's probably a spike here which I wouldn't be too worried about (a bit carefree?), but if you are, then just read on!

Pretty happy about how you were able to identify that your server is really overloaded? Sorry to hear that, but you never know because sometimes servers are able to handle much more load than the load shown. The load averages aren't so accurate afterall and cannot always be the ultimate deciding factor. Confused? It was just some technical information you don't need to be so bothered about. Move ahead if your loads are something to worry over.

* note the usage of term "reported". I have used this term because a P4 CPU having HT technology will be reported as 2 even if you know your server has one CPU.

II) Where's the problem?

To identify the problem, you need to run a series of logical tests (Ok, it isn't as scary as it may sound). All you need is some free time, probably 30-45 mins, and root access to your server (expect no magic ;)). Ready to start? Let's go!

Note: Perform the checks multiple times, to reach a fine conclusion.

1. Check for RAM (most common bottleneck!).

# free -m

The output should look similar to this:

# free -m
total used free shared buffers cached
Mem: 1963 1912 50 0 28 906
-/+ buffers/cache: 978 985
Swap: 1027 157 869

Any reaction like, "Ohh Gosh, almost all the RAM is used up."? Don't panic. Have 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 isnt't using much swap, you're pretty fine on RAM. Your server starts to use SWAP (much like Pagefile), which is part of your disk mapped as memory but it is comparatively very slow and can furthur slower down your system if you have a busy hard disk (which I doubt you wouldn't if you're using so much RAM). In short, at least 175mb available in buffers and no more than 200mb swap.

If RAM is the issue, you should probably look into optimizations on your PHP/Perl scripts, MySQL queries + server, and Apache.

2. Check if I/O (input/output) usage is excessive

If there are too many read/write requests on a single hard disk drive, it will become slow and you'll have to upgrade it to a faster drive (with more RPM and cache). The alternate option to a single faster drive is splitting the load onto multiple drives by spreading the most request content onto multiple drives, which can be easily accomplished using "symlinks" (soft links to files/folders). To identify, if your I/O issue is making your server lag:

# top

Read the output under "iowait" section, for each CPU. In ideal situations, it should be near to 0%. If you do however are scrutinizing at time of a load spike, consider rechecking these values multiple times to reach a fine conclusion. Anything above 15% is worrysome. Next, you can check the speed of your hard disk drive to see if it's really lagging:

If you do know your hard disk exists on /dev/sda or /dev/hda, just perform the following. Or execute "df -h" command to check which is the drive that your data resides on.

# hdparm -Tt /dev/sda

The output:

/dev/sda:
Timing cached reads: 1484 MB in 2.01 seconds = 739.00 MB/sec
Timing buffered disk reads: 62 MB in 3.00 seconds = 20.66 MB/sec

It was awesome at the buffer-cache reads, most probably because of the disk's onboard cache, however, buffered disk reads is just at 20.66 MB / sec. Anything below 25MB is something you should worry about.


3. CPU power is all consumed?

# top

Check the top output to find out if you're using too much CPU power. You should be looking the value under idle besides each CPU entry. Anything below 45% is something you should really worry about.


III) Problem identified, What's the solution?

To wrap it up, let me offer a few solutions for each problem:

A global solution to all problems is to optimize MySQL, and Webserver including PHP/Perl scripts and queries. Or the least you can do is to optimize Apache and MySQL server parameters to perform 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 better optimize your scripts and queries, if possible. In most cases, it's extremely difficult to optimize all the scripts and queries and a better option is to just go for a CPU change/upgrade. A dual CPU should perform better, but what kind of upgrade you're looking for depends on your current CPU.

2. RAM's all exhausted
It's like you're in the same kind of situation as the CPU one. Optimize HTTP, MySQL, scripts etc. or go for a RAM upgrade. You may install Opcode cache softwares like APC (from Pear) for PHP to make it perform better while decreasing the load.

3. Disk's all used (eh, I don't mean space)
Here you either have to go for a faster disk like SATA over normal IDE or SCSI over SATA. Well, I was just speaking generally. You have consider factors like RPM and cache to end up going for an upgrad that's worth it. The second option is to get multiple drives of the same class and spread the load across drives. One common methodology is to serve MySQL from a second drive.

IV) Conclusion

That wasn't of much help? My article might be flawed, ahh, excuse me. It's my first article and this thing really consumed quite a few braincells of mine. That's a bit personal isn't it? Let's get back to business.

FYI, In the example, the problem was with the I/O usage and hard disk getting slow.

A guide can never be complete in itself or offer you everything you will need to reach upto expert level (you need to keep learning to reach that level). Whenever in doubt, please DO hire experts to look over your server. Somehow, if you don't have the money to spend, you're stil safe! You can head to our Server optimization help section to get help with your server optimization.

Author and Copyright

Asad Khan is a web developer with passionate interest in PHP coding and Server Optimization.

Copyright 2006, Asad Khan & SpiceFuse. May not be reproduced in any form without permission.