Linux Tuning Tricks?

Milo_Mindbender writes: "Over the weekend I was attempting to improve my CD ripping performance and discovered RedHat 7.2 was running my Ultra/ATA 100 hard drive in a very slow non-DMA mode. After a fair amount of searching for how to fix this, a trivial change (look here) improved drive performance from 3MBs to 38MBs! FSCK on my 40gb partition went from over 5 minutes to under 1! This issue wasn't documented in RedHat's manuals but it effected a number of boxes in our office so I'm betting many other people in the world have the same problem. This made me wonder how many other common Linux tuning snafus there might be that a lot of people are probably missing. Do you know of any?"

Comments

A very nice, recent article ...

[hubie]

Linux Journal has a nice article on fine-tuning your system (doing things like recompiling the kernel with the best compiler options and optimizations (it also covers hdparam).

My only gripe with LJ articles is that, even if you put them in print mode, they still run off the end of my paper when I print them.

Check for interrupt clashes, and test

[Mark Wilkinson]

We recently built a machine around an Abit VP6 with 5 hard disks on it (three on the main IDE controller, 2 on the HighPoint 370 secondary controller). After a few days I noticed we were getting bad blocks on the drives on the HighPoint controller. Running badblocks on the disks gave random errors all over the place.

I then noticed that the Ethernet card was being given the same IRQ as the IDE controller and got suspicious. I swapped the ether card into different PCI slots until it got its own IRQ, then ran the badblocks check again. Everything ran clean.

It's also entertaining to use lmbench to test your hardware: it can plot pretty graphs showing how the IO speed changes across the disk surface so you can decide where to put your partitions, if that's important to you.

Main point though: if at all possible tune your hardware and then test using badblocks, lmbench and such before you put the machine into production (or when you've got a solid backup). As the article says, problems with your disk subsystem can loose lots of information quickly.

Careful with hdparm!

[dead_penguin]

If you are going to be playing with hdparm, take my advice and make a backup first! Some interfaces aren't fully supported by the kernel yet, and trying to run drives off of them in certain modes could break in a bad way. In my experience, this then means massive filesystem corruption and a complete reinstall.

Of course I'm not saying *don't* play with hdparm; just be sensible and only try it on a system you have backed up and can afford to lose for a little while as you're rebuilding it.