| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
hdparm
You don't need to do all these things by the way, only those that you need or want to, the rest are optional. Be aware that if your box is reasonably configured to begin with (and most distributions are, out of the box), you are unlikely to get a dramatic improvement from any one of these things.
However, by doing some or all of them you should end up with a system that boots more quickly, has more disk space and slightly more free memory, and a small but noticeable improvement in performance. The one thing you can do that will have a profound effect on performance is run lightweight, efficient software, so you should make that your first priority when building a fast Linux desktop.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
I'll assume you'll be running a SysV type system, as this is the most common and what you'll have if you are running a Red Hat-type distribution. SysV simply refers to the way services etc are started at boot time. If you are running some other system, you can still clean up the boot process; check your distribution's documentation for details. It's a good idea to browse through any documentation that came with your distribution anyway. This might be in the form of HTML files or a printed manual, and with many modern distributions is very comprehensive. The documentation should be able to provide you with details of any variations to the boot process used by your particular distribution, though I think the common distributions are pretty much all the same in this regard.
If this is a fresh installation, you should make sure all your hardware is properly configured first. Linux has really come a long way as far as hardware recognition goes, and chances are you won't have to do anything, though things like sound cards sometimes have to be setup manually. Once you are sure everything is going to work, you can continue with the tuning ....
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
After the kernel is kicked into life by GRUB or LILO or whatever, the following steps occur (with possible minor variations):
init program is started.
init then runs a script (usually `/etc/rc.d/rc.modules') to
load auto loaded kernel modules.
init then starts or stops all the services in that particular
run level directory. For example, if runlevel 5 is the default according
to `/etc/inittab', then all the scripts in `/etc/rc.d/rc5.d/'
are run.
init then runs another script (usually `/etc/rc.d/rc.local')
. This is where the user can put stuff that he/she wants to be started
automatically at boot-up. You might want to start your OSS sound driver
from here for example. Users of older versions of Mandrake can edit this
file to get rid of that damn ugly penguin ....
This is a bit over-simplified, but I hope you get the idea. If you take a look at the scripts in `/etc/rc.d/rc5.d' (or whatever your default runlevel is), you'll see that the names of the scripts all start with an S(for Start) or a K(for Kill or stop) followed by a number. The number determines the order in which the scripts are run. Most distributions start a diverse range of services or daemons at boot time, and while this automatically covers the needs of the majority of users, it also means that there will probably be several processes started that aren't required. This results in longer boot-up times, increased memory usage, and more potential security holes. Stripping un-needed stuff from the start-up scripts is easy; the hard part is determining what does what, and what you do and don't need. Hopefully the listing below will be of some help, it notes some of the most commonly found services and gives a brief description of what they do. And don't forget to make backups or notes of your changes, just in case you find you really did need to have that daemon started after all .... (this list is courtesy of Stan and Peter Klimas' Linux Newbie Administrators Guide)
anacron
cron jobs that were left out due to down time and executes
them. Useful if you have cron jobs scheduled but don't run your
machine all the time--anacron will detect that during bootup.
amd
apmd
arpwatch
atd
autofs
amd).
bootparamd
crond
/tmp directories, etc.
cupsd
dhcpd
gated
routed and egpup.
gpm
httpd
inetd
xinetd instead.
isdn4linux
kerneld
klogd
/var/log/kernel.
kudzu
keytable
linuxconf
lpd
mcserv
named
netfs
network
nfsd
nfslock
numlock
pcmcia
portmap
postfix
random
routed
rstatd
rusersd, rwalld
rwhod
rwho(1) and
ruptime(1) programs. Its operation depends on the ability to
broadcast messages on a network.
sendmail
smbd
squid
syslogd
smtpd
usb
xfs
xntpd
ypbind
Many users will find they have a lot of unnecessary stuff in their
/etc/rc.d/rc*.d/ folders. If you aren't sure if you need something or
not, just move it somewhere else temporarily (but don't delete it),
re-boot and see how things go. If you find that you do need it, just move
it back and re-boot.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
/etc/rc.d called JunkFromRc5 or something similar. Then I
just drag the unneeded scripts from /etc/rc.d/rc5.d/ into the new
folder (obviously my default runlevel is 5, you might need to use
something different..). Alternatively, you can use a graphical tool
like tksysv, or perhaps your distribution has it's own tool. You might
also want to edit `/etc/rc.d/rc/local'. Apart from user's entries,
this often has a few lines that overwrite `/etc/issue' with some
system specs (and/or that hideous penguin), and the contents of the
`/etc/issue' file are displayed just before the login screen. Many
people prefer to delete this bit and insert a line to display a fortune
here instead, eg. /usr/games/fortune > /etc/issue. As usual, if
you aren't sure what you are doing, make a backup copy of the file
first.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
kpackage) and spend some time browsing
through the list of installed programs. Tools like kpackage are ideal
for this kind of work as they can easily show you the size of each
package, a summary (so you know what the package is for), and any
related dependencies.
Do you really need six editors, four file managers, five shells, three ftp clients etc.? Don't be surprised to get rid of a hundred megs or more of stuff. Packages like the Tex related ones, Emacs/Xemacs, and various emulators are never used by many, yet they occupy lots of space. If you are doubtful about removing some packages, keep some notes so you can re install them later if you have to.
Many distributions also install lots of documentation (check out
/usr/doc or /usr/share/doc ). You'll probably find that
there are only a few files in there worth keeping, and remember most of
this stuff is available on the Web anyway. The du tool is
invaluable for finding disk hogs. Also look for core files left over
from crashes; these are only really useful to debuggers and can be
deleted.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
hdparm, a command line tool for setting (IDE) hard disk
parameters. The claimed gains are sometimes in the order of several
hundred percent. While I'm not doubting these figures, I have to wonder
whether they just indicate that the disk was horribly mis-configured to
start with. I've tried using hdparm on a few disks, and have found
modest gains in performance. Keep in mind that disk performance is only
one factor in overall system performance, and even a fairly big jump in
disk performance might not make a perceptible difference to the overall
speed of your system. If a disk was noticeably slow, I would certainly
give hdparm a try, but otherwise I wouldn't worry about it too
much. Some common distributions already set some of the optimizing parameters
at boot time anyway, so as I said before, unless you think there is a
problem, you could probably just leave well enough alone. If you do
decide to give it a go, make sure you read (and understand) the man page
(at a terminal emulator type man hdparm), and be aware that with
some of the adjustments there is a small but real risk that things can
go spectacularly wrong, ie. corruption of the file system. If you'd like
to give hdparm a try, here's the basic usage: hdparm [-flag]
device
Running hdparm without any flags (or with the -v flag) will
display the current settings. To see the current settings for my first
hard disk (/dev/hda) for example, I would use: hdparm
/dev/hda. To do a basic check of the speed of the first hard disk I
would use: hdparm -Tt /dev/hda. Some more commonly used flags:
-c3
-a [sectcount]
-m16
-u1
-d1 -X34
-d1 -X66
I guess the logical way to use hdparm would be to find out what your disk supports, then set hdparm accordingly. More commonly though, trial and error is used, changing one setting at a time and measuring the performance after each change. Don't use settings recommended by someone else ; while they may have worked perfectly on that persons disk, your disk might be completely different and the results may not be good. There are several tools available for testing disk performance, one of the better known ones is bonnie. And remember the changes will be lost when you re-boot, so if you want to make them permanent, you'll have to add them to a boot script like `/etc/rc.d/rc.local'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
noatime to the mount options
listed in `/etc/fstab'. For example: /dev/hda5/ ext2 defaults,noatime 11 if you do
not wish to update last access time on the files in /dev/hda5
partition.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Obviously you'll be aiming to conserve memory as much as possible. Use
the free command from a terminal emulator to see memory usage
details. Ideally, you'll be able to balance usage against available
memory so that swap isn't used.
You can save some memory by using a plain background on your desktop, rather than an image file.
Other useful tools are ps -aux (shows details of running
processes), and top (similar to ps but continually updates).
Help reduce the time it takes X to update the screen on low-end machines by not using a greater colour depth than necessary, eg. use 16bit instead of 32 bit. You can check X's performance with x11bench, which is often installed by default.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |