Linked by Thom Holwerda on Sun 23rd Apr 2006 16:35 UTC, submitted by Mark
Linux "Why tune my system? This is probably the first thing you want to know. When a distribution is packaged and delivered to clients, it is designed to be fully compatible with most of the computers available in the market. This is a very heterogeneous set of hardware (hard disks, video cards, network cards, etc.). So distribution vendors like Red Hat, SuSe, Mandriva and the rest of them choose some conservative configuration options to assure a successful installation. For instance, probably you have a very advanced hard disk with some special features that are not being used due to standard configuration settings. To summarize: your Linux distribution goes well... But it can go even better!"
Order by: Score:
Sata instead of hdparm
by netpython on Sun 23rd Apr 2006 17:15 UTC
netpython
Member since:
2005-07-06

Timing cached reads: 2104 MB in 2.00 seconds = 1051.93 MB/sec
Timing buffered disk reads: 176 MB in 3.02 seconds = 58.20 MB/sec

I Would buy faster hardware or overclock.

Reply Score: 1

RE: Sata instead of hdparm
by billnvd on Sun 23rd Apr 2006 18:04 UTC in reply to "Sata instead of hdparm"
billnvd Member since:
2006-02-04

Timing cached reads: 2808 MB in 2.00 seconds = 1403.51 MB/sec
Timing buffered disk reads: 242 MB in 3.00 seconds = 80.65 MB/sec

I was thinking the same about your numbers. I guess two cheap ass $40.00 ata100 WD's on software raid provide better bang for the buck. Add $70 for a Semprom64, a $40 for a k8u/x and $50 worth of Ballistix. 240 bucks! Hope you did not spend more!

Seriously though, raw numbers like provided by hdparm are pretty useless about how the system will feel to a user. Not long ago, I was running a Athlon MP2400 dual rig. It used ECC/pc2100 ram and only had buffered reads around 500 MB/sec and raw reads around 40 MB/sec(HW RAID Mirror). It felt far faster than this rig, Cost a crap load more too!

So, even with 1/3 the Mem BW and 1/2 the disk reads, the dual made this thing seem slow. Of course, it was noisy, hot, and pricey. It is now someone elses problem. This rig is quiet, cool and affordable.

Reply Score: 3

Sad
by Morin on Sun 23rd Apr 2006 18:20 UTC
Morin
Member since:
2005-12-31

<EDIT> at the beginning: It's sad that one has to say it in this forum, but to please the fankids: Windows is no better! </EDIT>

The only excuse for this being needed is that many hardware pieces don't support HW detection properly. I'm still waiting for someone to combine *fixed* hardware with F/OSS software to produce a system that can actually be described as "user-friendly" (the F/OSS Mac, if you want).

Why I think system-tweaking is bad? Because it's unnecessary. You can do it right or wrong, but there's only one way to do it right, so the system could as well do it automatically. Now to the details:

"Disabling system services"

Sure, if you are intending to run Linux in an embedded device, you are going to remove whatever possible. But for the normal user, I just have to ask: As long as these services are not used, why do they consume any noticeable amount of system resources?

"Disabling X at booting."

This is a valid point for those who don't use X.

"Removing consoles"

Again, why do unused consoles take so much resources?

"Hdparm"

Hardware should work at full performance out of the box without tweaking. There's just no sensible reason for anything else.

"Sysctl"

I'm not experienced with this, and the article explains no detais, so I can't comment on this.

"Installing video card drivers"

User-unfriendly is user-unfriendly, even though not including proprietary drivers in a distro that is committed to F/OSS principles is an honest choice. It's sad that too many people confuse these entirely different areas. This is the second big reason (besides braindead-designed, legacy-compatible hardware) to build an entirely open system together with its own hardware (or hardware combination).

"Drivers for frequency scaling"

Again, the feature should be detected, drivers be installed, and CPU frequency be adjusted automatically.

"I want more: Compiling your linux kernel (the easy way...)"

Now it's getting ridiculous... Is this an article for users or for distro-builders and kernel developers?

Edited 2006-04-23 18:22

Reply Score: 3

RE: Sad
by siride on Mon 24th Apr 2006 03:34 UTC in reply to "Sad"
siride Member since:
2006-01-02

The reality is that most of these things don't actually make a difference and hardware detection does work on most computers.

The only difference here between Linux and Windows is that Linux gives you, the user, low-level direct control over these things, whereas Windows generally doesn't (at least without a whole lot of digging and special software). So that means a bunch of ricers come along and try to tweak to get an extra 0.1% performance.

Reply Score: 3

Small change
by moleskine on Sun 23rd Apr 2006 18:46 UTC
moleskine
Member since:
2005-11-05

What has made a difference here? Buying more ram (now 1 gig), making sure my disks are running at their best via hdparm, shutting down unused services. I don't think you can ask Joe User to do much more. Ubuntu installs cpu frequency stuff on my notebook anyway. 3D Nvidia drivers, yes, but they are fairly easy to install and I would not need them if I didn't use 3D.

More fiddling: recompile kernel and modules after changing a few settings (latency, optimize for my flavour of cpu, etc.), particularly with SuSE which seems to choose conservative, server-based settings for everything. When recompiling the kernel and modules (but not individual programs) I change the compiler settings to, in my case: CFLAGS="-march=i686 -O3 -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -pipe -fomit-frame-pointer -fweb"

The result is a nippier machine. This is a p4 desktop so I can take chances, but I can't be arsed to take things further by messing with sysctl and the rest. Stability still matters, and a slow and ponderous DE (like older versions of Gnome) can and will undo all this work anyway.

Maybe distros will start to offer two flavours of kernel: slightly slower and very safe for servers, and faster and more cutting edge settings for home/desktop users. Maybe some distros already do?

Reply Score: 2

RE: Small change
by gpierce on Sun 23rd Apr 2006 19:19 UTC in reply to "Small change"
gpierce Member since:
2005-07-07

It sounds like you are a Gentoo user. Do you specify the CFLAGS in the /etc/portage/package.use file? Because, I was not aware you could do that for individual programs like you could with USE variables.

Reply Score: 1

RE[2]: Small change
by moleskine on Sun 23rd Apr 2006 19:47 UTC in reply to "RE: Small change"
moleskine Member since:
2005-11-05

It sounds like you are a Gentoo user. Do you specify the CFLAGS in the /etc/portage/package.use file? Because, I was not aware you could do that for individual programs like you could with USE variables.

No, I am a Debian user and sometimes a SuSE user, with Ubuntu on laptop. Gentoo sounds like too much work to me. I do it by placing the flags in my .bashrc file. Log out and log in again to activate. When I don't need them any more, I comment them out and repeat.

Reply Score: 1

RE[3]: Small change
by swzk on Mon 24th Apr 2006 12:25 UTC in reply to "RE[2]: Small change"
swzk Member since:
2006-04-24

I'm sorry, but this is stupid.
First of all, setting CFLAGS as an environment variable has no effect on kernel compilation. Second, -march is set depending on what you choose for processor family option, for p4 it is set to
-march=i686 -mtune=pentium4, -fomit-frame-pointer is enabled by default, unless you specify CONFIG_FRAME_POINTER=y option.
-funit-at-a-time is enabled with -02 which is kernel default.
-fweb -funswitch-loops are enabled with -03. and -03 is known to brake things.
man gcc wrote:
-funroll-all-loops
<snip>This usually makes programs run more slowly.
The result is a nippier machine.
No. The result is placebo.
Stability still matters, and a slow and ponderous DE (like older versions of Gnome) can and will undo all this work anyway.
How exactly a slow DE is helping to improve stability?

Reply Score: 1

Useless Info
by zlynx on Sun 23rd Apr 2006 19:34 UTC
zlynx
Member since:
2005-07-20

I was hoping for an article with more meat. Where's the info on adjusting disk schedulers, queue depth, read-ahead? How about adjusting network settings for good gigabit performance? Where's the best settings for binding server processes and network interrupts to CPU nodes in a 4 chip, 8 core Opteron NUMA box? Or optimizing filesystem settings in combination with choosing the best RAID stripe size?

Reply Score: 1

RE: Useless Info
by sanjos on Mon 24th Apr 2006 04:42 UTC in reply to "Useless Info"
sanjos Member since:
2006-04-24

If you didn't notice, the article is aimed at desktop users. 4 chip, 8 core Opteron NUMA box with RAID.. for a desktop??? wow !

Reply Score: 1

What he forgot to mention...
by SEJeff on Sun 23rd Apr 2006 20:49 UTC
SEJeff
Member since:
2005-11-05

The author forgot to mention a few things that I like to do when tuning my linux systems.

For all of my ext3 volumes, I enable dir_index for a slight speed increase with 0 effect on stability.
tune2fs -O dir_index /dev/hda2

Disabling ipv6 if you don't use it (99.9% of the normal user population). These commands work on my Ubuntu/debian systems. It might be different on rpm based distros.
sudo echo "alias net-pf-10 off" >> /etc/modprobe.d/aliases
sudo echo "alias ipv6 off" >> /etc/modprobe.d/aliases

Don't let the kernel swap as much by lowering the swappiness setting. The kernel default is 60 and
setting it to 0 is the same as not using a swap partition, DONT DO IT!
sudo echo "vm.swappiness=10" >> /etc/sysctl.conf
sudo sysctl -p

Speed up gnome a bit:
gconftool-2 --set --type boolean /desktop/gnome/interface/enable_animations false
gconftool-2 --set --type boolean /apps/panel/global/enable_animations false
gconftool-2 --set --type string /apps/nautilus/preferences/show_image_thumbnails never
gconftool-2 --set --type string /apps/nautilus/preferences/show_icon_text never
gconftool-2 --set --type string /apps/nautilus/preferences/preview_sound never

TFA's author is vague on hdparm. Here is what I use on any newer drive I get:
sudo /sbin/hdparm -u1 -m16 -c1 -A1 -a64 -d1 -K1 /dev/hda

I also disable many default services and majorly disagree with disabling iptables from loading firewall rules on system boot. That takes extremely minimal resources and secures the system. I've got a few more tweaks laying around somewhere on my disk, but can't find them at the moment. This should be good enough for most.

Reply Score: 3

RE: What you forgot to mention...
by sanjos on Mon 24th Apr 2006 04:31 UTC in reply to "What he forgot to mention..."
sanjos Member since:
2006-04-24

Kernel patchs by Con Kolivas.
Linux scheduling latency (2.4.x kernel).
Re-compiling applications for specific arch.
I'm sure there are lots more. Again, the potential benefits and trade-off is debateable and it may or may not work in your environment.

Reply Score: 1

SEJeff Member since:
2005-11-05

There are only 2 main things that it *really* helps to recompile and optimize for your architecture...
-the kernel
-the c library

Anything else will normally speed up things, but the increase is minimal as the bottleneck will always be the hard drive. Most distros ship a linux*-686 or a 64bit kernel.

Reply Score: 1

RE: What he forgot to mention...
by Tom Janowitz on Mon 24th Apr 2006 09:15 UTC in reply to "What he forgot to mention..."
Tom Janowitz Member since:
2005-12-05

Maybe it would be good to mention that those switches for nautilus are easily accessible from nautilus -> Edit -> Preferences -> Preview - it doesn't have to look as black magic ;)

Question (not that I express any doubt) : are there any real life benchmarks of how does swappiness influence performance ? I know it does (usually), but what I would like to see is real numbers. The same with regard to 'dir_index'.

Reply Score: 1

time
by Babi Asu on Sun 23rd Apr 2006 23:31 UTC
Babi Asu
Member since:
2006-02-11

Time gain from performance improvement is much less than time needed for tuning and testing.

Reply Score: 2

Not bad
by cerbie on Mon 24th Apr 2006 11:31 UTC
cerbie
Member since:
2006-01-02

services: OK, I'm running cron, and not using it. Got me. Most of the services I'm running I either need, or might use.

Disable X: why not just use a distro that doesn't automatically start it? I'm a command-line user, too, but a GUI is even handy for that--multiple Konsoles and Eterms! For a server, yes, it should be off, but for a desktop, it's kind of handy.

Removing consoles: hey, I use my other consoles, and terminal apps in X. And if I didn't--exactly how much CPU time are they eating?

hdparm: OK, that was interesting. Don't know how useful, but I'll give in for this one.

Sysctl: interesting, but...

Drivers: if someone wants them, they're easy to get, and are generally not used for performance more than features.

CPU speed: n/a (I use my BIOS for underclocking and overclocking)

Kernel compiling: yes, quite handy, and can speed up boot time by removing tons of stuff. I'm not sure I'd do this in any environment but my own PC, though.

While not terrible, I would really have liked to see more meat to the tuning, like filesystem performance, and actual options that go good from Sysctl (and what ones are good to avoid), and what you can actually change for X (other than drivers) that may help it out.

Reply Score: 1

shortening boot up time
by Tom Janowitz on Mon 24th Apr 2006 13:10 UTC
Tom Janowitz
Member since:
2005-12-05

There are few inits that perform boot procedure of many services in parallell (if possible & depending on the design) resolving dependencies :

cinit
http://wiki.clinux.info/index.php/Cinit

initng # I guess still a bit buggy but with very encouraging results
http://www.initng.org/wiki

runit # very simple (only few hundred lines of code) system init with service supervision
http://smarden.org/runit/

...and one more :
http://www.improvedsource.com/view.php/Linux-System/3/

Although it's not about overall system performance it sure makes at least one job most (dektop) systems perform everyday faster : booting.

Reply Score: 2