Slashdot Mirror


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?"

15 of 71 comments (clear)

  1. disable system services on startup by babychess · · Score: 3, Informative

    On RedHat, you can use ksysv, the init editor, to turn off boot-time system services that are not needed. Candidates are daemons for GPM, USB, SCSI, LPD, APM, which are all enabled by default, and which may not be needed.

    1. Re:disable system services on startup by eufaula · · Score: 3, Informative
      with redhat (maybe others) you can also run the command "setup" and have a curses-based way to do it. or, you can go into /etc/rc3.d (or whatever runlevel your distro/os normally runs at) and move the S##xxxx scripts to K##xxxx to prevent them from starting. this is the standard way of starting/stopping services on SYSV UNIX, so this holds true for Solaris and others.

      -- aside -- you CAN move them to anything other than S##xxxx, but i normally stick with the standard and use K##xxxx

  2. Prostitute Penguin by JonBob · · Score: 4, Funny

    I had to read this story's subject three times before I realized it did not say "Linux Turning Tricks."

    1. Re:Prostitute Penguin by EnVisiCrypt · · Score: 3, Funny

      I thought the same thing when I read the headline.

      > "Linux Turning Tricks."

      I could make a joke about open "sores", but I won't.

      --


      *everything* is Orwellian to cats.
  3. A very nice, recent article ... by hubie · · Score: 5, Interesting
    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.

    1. Re:A very nice, recent article ... by dubl-u · · Score: 3, Funny

      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.

      So I just looked up this "paper" thing on Google, and it sounds really cool, kinda like a flat-panel display with a built-in battery. But how do you slice the trees so thin?

  4. UDMA, etc. by linuxator · · Score: 3, Interesting

    The truth is, that even on "leading desktop OS" called with a name that reminds sheet of glass between frame, has not UDMA/66 and higher mode turned on by default.

    Problem is, that it breaks compatibility with older hardware... eg. you will put an old harddisk on your comp. and it will "blow up" becouse your fancy OS will think it can take faster transfer speeds... etc.

    --
    * Origin: XBase BBS (2:490/4100) Well the good old days may not return and rocks might melt and sea may burn.
  5. Check for interrupt clashes, and test by Mark+Wilkinson · · Score: 5, Insightful

    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.

  6. Re:wow.. I never knew that.. by Sentry21 · · Score: 3, Interesting

    Amen to that. I had an old fujitsu hard drive, and I started playing with hdparm one day. Basically I turned on every possible option, including the ones marked in the man page as 'this will probably cause extreme filesystem corruption' and 'what are you, on crack? get the hell away from here!', and it worked great. Performance was simply excellent.

    Overzealous, I recommended these options to friends, who all locked up when they tried them (pinging out from IRC, etc), but I was undaunted. When my old HD started to give up the ghost, I got a new (well, new to me, this was 6 months ago) 2 gig WD for the box, and turned all the options on. Hours later, the entire filesystem was corrupted. After the whole system nosedived, I spent more than two hours hitting 'y' in fsck before I decided 'screw it' and reformatted. Fortunately, it was a clean install anyway.

    Moral of the story: test out your psychotic options before you put any important data on the drive. Other moral: say what you like about fujitsu, but their drives support more hdparm options than any other I've seen, and they don't break when you use them.

    --Dan

  7. Careful with hdparm! by dead_penguin · · Score: 5, Informative

    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.

    --

    It's only software!
    1. Re:Careful with hdparm! by dimator · · Score: 3, Interesting

      People, don't pretend you're cool and not make backups, thinking that nothing will happen if you go screwing with hdparm. I learned the hard way, and now I'll be digging up all my $HOME directory from cryptically named files in lost+found. It should be a fun night.

      I have only myself to blame.

      --
      python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
  8. Distributing software but not knowledge = problem by tshoppa · · Score: 4, Insightful
    While Redhat is pretty good at making a distribution that boots and installs on a very wide number of machines, it's not so good at making this distribution be high-performance. Many things are set to the safest possible value (like the OP's IDE DMA modes) when a much more reasonable value would work on 99% of the hardware out there.

    Life is made more difficult because there is buggy and/or broken hardware out there. I don't blame Redhat for accomodating this hardware, but by doing so they are making their distribution more complicated and less useful for those "in the know".

    Redhat also, of course, distributes the non-kernel binaries optimized for Intel 80386 CPU's when the vast vast majority of installs are going on Pentium-class or better machines. And it doesn't help any that Redhat is using and distributing a very nonstandard version of GCC; see what the GCC developers say about such branches and what application developers say about this branch.

    To actually learn a lot about Linux and all the associated tools that make it work, I highly recommend the Linux From Scratch method: build everything from source! You can optimize the build to your machine and end up with not only better performance, but a vastly superior knowledge of everything that used to be "under the hood".

  9. Re:PCI Bus speed by Gothmolly · · Score: 3, Informative

    Your PCI bus speed IS 33MHz, unless you are overclocking or running a new, rare, high-end box.

    --
    I want to delete my account but Slashdot doesn't allow it.
  10. Powertweak and /proc twiddling by embobo · · Score: 4, Informative

    You may try to use Powertweak to alter settings to improve performance.

    Then there is tweaking settings via /proc. I used to have a link to some excellent documentation on it but, alas, I can't seem to find it. You could try reading the various bits of info in the Documentation tree of the Linux source but it is pretty spartan.

  11. "Tabilize".... Or just use plain text. by Bob_Robertson · · Score: 3, Insightful

    I agree that wide tables are annoying, but HTML viewers (and printers) nicely re-wrap plain text to fit.

    Sooooo much easier than tables is just to use preformatted text.

    Just a side comment from someone who has always written his web page in vi.

    Bob-

    --
    The Ludwig von Mises Institute. The reasoning individuals economics