Linux

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.

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

11 comments
tbmay
tbmay

That's just fine if NECESSARY. But it is absolutely impractical for anyone who has lots of servers to manage. Come'on Jack. There's theory, and there's the real world.

ehtom
ehtom

Harware: Fastest drives available Use ext3 File system Understand raid and what it can do for you Raid 0 : striping offers superior I/O performance But raid 5 offers better redundancy. Always use a hardware controller with the biggest cache you can afford. Network: Not much point in having lightning fast NICS on your server if your LAN is 10/100 Find the bottle-neck and fix it Memory speed: Make sure you are using DDR3 DDR4 will be available this year but there may be motherboard compatibility issues Monitor, Monitor, Monitor Use a realtime charting application like Munin This has the lowest power to weight ratio of any monitoring app and its free To find out what your server comprises of hardware wise. Run lshw as root Yum install lshw if its not there This will give you a complete (in html) list of hardware Always use a 64Bit OS Why: there are 64 tracks going from the processor to the memory banks A 32 bit OS will only use 32 of these tracks per clock cycle.

pgit
pgit

How about a hands-on, concrete-examples article on SELinux? I have been looking into this as a background project and elsewhere said looking at it is akin to "a shot of pepper spray point blank in the eye." One practitioner began his introduction to SELinux saying "it's not for the squeamish." It'd be nice to have someone start of with, say, a basic rc and config files... or is that asking too much? :)

Alpha_Dog
Alpha_Dog

...is the order in which these things should be addressed. Good job Jack! Revised order: 1. During install, can the GUI (generally for servers) 2. Kill services that are not needed (Good advice for any OS) 3. Keep updated. While modern Linux is good about this, it doesn't hurt to check and kill orphaned packages. 4. Compile software from source, though this may have mixed benefits given the unknown dependencies the package manager takes care of. 5. Pay close attention to SELinux. Most don't know how and this is one of the things that separates men from boys in the Linux world. LEARN IT!

Brainstorms
Brainstorms

I question whether Raid 5 is a good choice over Raid 1, esp. in this day & age of cheap, large hard drives. Raid 5 tends to thrash your disks with constant re-writes of parity data; why tolerate that to save buying one or two drives? Raid 1 may use more disks, but is simpler and can be faster; disks are now cheap. A server can have the best of both worlds by implementing Raid 1+0 (striping mirror sets) to get speed + redundancy (including the ability to tolerate multi-disk failures) -- all without the constant re-writing of parity to implement a complicated reconstruction scheme. Raid 5 seems obsolete to me. Also, I think 64-bit refers to the register size (and hence the addressing space), not the data bus width. Processors since the Pentium Pro (i686) have had 64-bit external data buses, long before 64-bit CPUs hit the market. Instructions in 32-bit processors exist to use all 64 data bus tracks whenever possible, such as fetching (or pre-fetching) two 32-bit operands --or multiple instructions-- simultaneously, just as a 64-bit CPU does. If you don't need to process large operands, and you don't need to access huge data spaces, a 64-bit OS may not add that much. There's probably more to be had in faster RAM, faster hard drive architectures, and faster networking.

pgit
pgit

Why would you chose ext over ext4?

Alpha_Dog
Alpha_Dog

While it's true that SELinux is "not for the squeamish", the beauty of Linux is that we can make tools to simplify the administration of our big tools. In the absence of this, we can share tips and scripts to make all of our lives easier. Let's do this!

ehtom
ehtom

Yes, you are right. My vendor has been advocating Raid 1+0. But the admins in the far off lands that we implement our systems are old school and love the sound of parity checking. Also, I bow to your superior knowledge of architecture.

ehtom
ehtom

I choose ext3 over ext4 for production machines. Ext4 uses ???delayed allocation??? which can cause data loss

Brainstorms
Brainstorms

Old school.. Hope they're "old money", too, so they can pay for the prematurely dead hard drives... :^D Humor aside, there's another advantage to Raid 1 / Raid 1+0: I built a system for a guy with a small business, Raid 1, with a duplicate system off-site for backup. When he needed more space, adding another disk pair in each was easy (and LVM made it all the more so). But when his primary had a melt-down, all I needed to do was split the mirror on the backup, bring one set of disks to his business to re-create his server, and install replacement drives. After powering back on, he continued working as it reconstructed the array in the background (same with the backup system). No downtime to copy backups to the rebuilt primary as a Raid 5 would have required. Oh, and the thing about 32-bit processors having 64-bit data buses is one of my favorite hardware trivia items; most people don't know about it. That EE degree is occasionally useful for something I guess... :^)

techrepublic@
techrepublic@

Most (probably all) of the production GNU/Linux systems I manage never crashed or freezed and UPSs take care of the power issues.