Five tips for improving Linux server performance

You can maximize the performance of your Linux server by making a few tweaks. Jack Wallen runs through some effective performance-boosting tricks.

Most Linux server distributions, out of the box, will outperform proprietary systems. But that doesn't mean there aren't things you can do to improve the performance of your server. In fact, there are always ways to eke out a bit more performance, no matter the operating system. But in this article, I want to speak directly to boosting the performance of the Linux server.

I've tried to make this as distribution independent as possible. There are instances where one particular issue depends upon a particular distribution or release, but I wanted to be as all-inclusive as possible.

1: Kill services that are not needed

This particular trick will go a long way toward improving the performance of your server. With some Linux servers, certain services seem to want to run by default, regardless of whether they are being used. If that is the case, make sure those services are not running. For example: Samba. If you're not serving files to Windows or other platforms, kill the Samba daemon. The same holds true for many other services. Your best bet is to decide what your server IS doing and then go through and kill what it doesn't need. This will also have the benefit of making your server more secure.

2: Pay close attention to SELinux

SELinux is an often misunderstood tool. Its purpose is to enhance the security of a server or desktop. It is there for a reason and should not be stopped altogether. It should, however, be configured to meet the specific needs of your server. SELinux is quite powerful, and if it's improperly configured, that power can rob your system of much-needed CPU cycles and slow down data throughput. If your distribution uses SELinux, be sure you have a strong understanding of it so you can fine-tune it to meet your needs.

3: Compile software from source

This might seem a bit counterintuitive, but when you compile your software from source, you can often run the compilation with flags and arguments highly specific to your hardware and/or needs. This goes for software that runs services and, of course, the kernel itself. The more hardware/need-specific you make your software, the more performance you will gain. Of course, this does require some experience with installing from source. I would recommend starting with this method on a test machine to get used to how the software can be better tailored to fit your situation.

4: Keep updated

This is insanely important from both a performance and a security standpoint. I see it so often: administrators ignoring updates for fear the updates will break their currently running software. If you are one of those admins, I recommend having a testbed server that mirrors your production server. With that testbed in place, you can run the updates prior to running them on the production machine so you will know precisely what could go wrong. From my experience, though, it's a rare occasion that something does go wrong with a Linux software update.

5: Can the GUI

If you really need as much performance as possible, you can do one of two things: Use a GUI-less server installation or run the server in run level 3. If you need the GUI to get the machine up and running well, you won't need that GUI running all the time. So instead of running GDM or KDM (and stealing resources), edit the run level so that the boot process stops at run level 3 - console login. This will not only save CPU cycles and memory, it will also circumvent the possible security issues of having GUIs running on your precious server. Each distribution edits the run level differently, so make sure you understand how to make this change before you attempt it.

More performance tricks?

Some of these tips are far easier than others, but each of them will gain you levels of performance your server wouldn't enjoy otherwise. Do you have a tip for getting the most out of your Linux server? If so, share it with your fellow TechRepublic readers.