All
the peripherals of a computer have to perform in such a way that the overall
performance of the system, say, for a typical home user is satisfactory.
Performance tuning in the right sense of the word is non-trivial, since the
term performance is incomplete without a context. However, for our purposes,
we’ll take a typical home/office user with his own desktop running Linux.
You’ve had your fun getting Linux going, but do you know whether you’re
getting as much out of your machine as it is capable of? Here are a few
basic tips on how to tweak your Linux machine to deliver that extra bit.
For your convenience, the
tweaks have been categorized under specific categories, such as disk
performance, video performance, etc. Before experimenting with any of these
tweaks, we strongly suggest that you backup your data as well as your
existing configuration.
IDE disks
The Linux
kernel has 16-bit EIDE support turned on by default. This can result in disk
I/O two to four times lesser than most modern disks are capable of.
The command:
# /sbin/hdparm /dev/hd* (a or b or c or
d depending on the configuration)
will show you the options in
use. You should see something like this:
mulcount = 0
(off)
I/O support =
0 (default 16-bit)
unmaskirq = 0
(off)
using_dma = 0
(off)
keepsettings
= 0 (off)
nowerr = 0
(off)
readonly = 0
(off)
readahead = 8
(on)
geometry =
1048/255/63, sectors = 16841664, start = 0
# /sbin/hdparm -Tt /dev/hd* will give you buffered and unbuffered performance figures for
your hard disk-IDE controller combination
# /sbin/hdparm
-c1 /dev/hd* will set the disk to use 32-bit
I/O
# /sbin/hdparm
-d1 /dev/hd*
will enable DMA. Note that
this depends on whether the IDE chipset of your PC motherboard is supported
by the kernel. Also, some older hard disks do not respond well to these
settings
# /sbin/hdparm -Tt /dev/hd*
will let you test the results
of the changes. Once you’ve found the optimal settings for your disk, run
# /sbin/hdparm
-k 1 /dev/hd*
to keep these settings across
an IDE reset.
My test machine has an Intel
BX board and a Seagate U8 disk. With default settings, I get a throughput of
4.3 Mbps. With 32-bit I/O and DMA turned on, I see 17 Mbps.
Most IDE chipsets are
supported by Linux 2.2.x kernel, with the exception of the Aladdin V
(ALI1541). There’s hope for people who own boards with the chipset yet.
ALI1541 drivers are available in the 2.3 development kernels and should soon
be available on production releases.
Swap partitions
Create swap
as close to the beginning of the disk as possible. This puts swap on the
outer portion of the disk so that the disk head can cover more area per
read/write.
When you have multiple hard
disks, spread the swap space evenly across them. When mounting them, set the
priority of each to same value. The kernel will now spread the swap load
evenly across the partitions.
File system
Linux
records information about when files were created and last modified. It also
records when these file were last accessed. This information isn’t very
useful and carries a performance overhead. This attribute is called atime
(access time).
Linux has a file system mount
option called noatime. When a file system is mounted with this
option, read access to a file will not result in the atime information for
the file being updated. The noatime option eliminates the need for a write
to the file system each time a file is simply being read. Since writes tend
to be expensive, this can result in significant performance gains. Note that
the wtime information is still updated whenever the file is written to.
# chattr +A
will set this attribute for a
file and
# chattr +A
-R
will set the attribute for an
entire directory.
A typical fstab entry
with noatime options looks like
/dev/hda6 /var/spool/news
ext2 defaults,noatime 1 2
Another method to improve
performance of the file system is to select larger block sizes at the cost
of wasting some disk space (1 kB files will now occupy 4 kB). Setting 4096
as the block size on a file system will result in less file fragmentation,
faster fsck’s, faster deletes, and raw reads. The command
# mke2fs -b
4096 /dev/
will format a file system
with a block size of 4096. Note that you need a good enough reason to do
this; typically, if you observe that the average file sizes that you have on
your home partition average around 4 kB, you might want to do this. As a
thumb rule, you might want to do this on a file server.
fast_vram option of video
cards
By adding a
fast_vram option to the Device section of your XF86Config file, you could
greatly enhance the performance of graphics on your machine depending on
your graphics card.
Section
"Device"
Identifier
"Video Card"
VendorName
"Unknown"
BoardName
"Unknown"
VideoRam 4096
Option ‘fast_vram"
EndSection
This option is known to work
with the SiS and AGX drivers.
Compiling and patching the
kernel
When
recompiling the kernel on an SMP (Symmetric Multi Processing) machine, edit
/usr/src/linux/Makefile. Replace
make=make
with
make=make -j
This speeds up the kernel
compiles by compiling multiple things at once, thereby fully utilizing the
SMP capabilities of your machine.
While patching the kernel,
you would normally use
# cd /usr/src;
gzip -cd patch-x.y.z.gz | patch -p0
This can also
be done by
# cp
# /usr/src/linux/scripts/patch-kernel
The script even takes care of
multiple patches, applying them in the right order.
Gnome desktop environment
Use "imlib_config"
to tune "imlib", and increase the size of the cache. This can
improve Gnome’s performance quite a bit. Too large a cache, however, might
result in swapping to disk, thereby slowing things down.
Double side printing
Some
Postscript printers support double-side printing. To instruct the
printer to use this feature, use "mpage".
mpage -t -1 -Pprintername
-bA4 file.ps
Use
"-2" or "-4" to print 2 or 4 pages on the same side of
the paper.
That’s the list of tips for
now. Like we mentioned earlier, some of these tips make changes to the basic
behavior of your peripherals or application software. And before you try any
of these tips, backup your data.
Avinash
Shenoy is a systems and network administrator at the NCBS, Bangalore,
and Gopi Garge is a technology
consultant with Exocore Consulting <www.exocore.com>
To understand what logrotate
can do, first ask yourself what you want to do with your log files. The
table "Planning for a log processing and archiving policy" might
help you to start. The first row lists the processing and reporting to be
done, while the first column lists the files on which the processing is to
be done. Put down the different log files in column 1, tick out the log
processing of your choice, and you can come up with a policy for using
logrotate.
Let me briefly explain what
each column implies. A "yes" on column 2 indicates that you want
to retain the log file as a record, so it’s best kept compressed.
Similarly, a "yes" in column 3 indicates that you merely want to
scan the file, look for the unusual, and then discard it. You might want to
mail this file to yourself or to the relevant administrator. Column 4 says
that you want to discard the file straightaway. In the sysadmin world, this
obviously doesn’t qualify for best practice. Columns 5 and 6
mention the actions you want to perform before and after you do the log
processing. Column 7 is for an e-mail address to which errors during log
processing are to be reported, and column 8 indicates how often you want the
processing to be done. Note that you might want a time threshold with a
granularity of a day or choose to have a file size threshold to rotate the
logs. This table is not exhaustive or mandatory in nature–it’s is merely
an example of how you would go about the policy-making exercise. So, don’t
implement this, as is, as a policy. Evolve one to suit your needs.
If you’re ready with a
table such as the one above, you have a policy. You can now use logrotate to
implement this policy.
The policy is specified using
keywords, as well as with a script-like language comprising keywords
specific to logrotate. The script is intuitive and easy to understand. By
default, most logs are rotated four times, uncompressed, before they’re
removed from the system. This should explain the presence of files with the
extensions .1, .2, .3 and .4 in the /var/log directory. Take the file /var/log/messages
as an example. After a certain time period or after a certain file size is
reached (as specified in /etc/logrotate. conf), this file is renamed to
messages.1 and an empty file called messages is created to take in the new
log input. This is repeated until they’re rotated four times.
Let’s look at a portion of
the configuration from /etc/logrotate.conf from a standard install. The
first line mentions the name of the file for which the policy is laid out.
Notice the intuitive keywords–"monthly" indicates that the
rotation cycle is monthly, "create" specifies the permissions and
ownerships to be used when the old file is moved to another name and an
empty file is created. "Rotate 1" indicates that one rotated
logfile will be retained:
/var/log/wtmp
{ monthly
create 0664
root utmp
rotate 1
}
Here’s a portion of the
file /etc/logrotate.d/apache–the policy for processing apache log files.
The keyword missingok implies that if the log file isn’t found, continue
processing the rest. Notice the command in between the keywords postrotate
and endscript. This command is executed after log processing is done.
Surprisingly, you don’t find any other instructions such as the frequency
of rotation or the number of rotations, as in the previous case. When there’s
no explicit mention made, the definitions in the global configuration file
will apply.
/var/log/httpd/access_log
{
missingok
postrotate
/usr/bin/killall -HUP httpd 2> /dev/null || true
endscript
}
logrotate is typically run
once a day by the cron. If you are logged in as superuser, you would see an
entry similar to the one below in the crontab file:
0 0 * * * /usr/sbin/logrotate
The utility runs every
midnight. You can run it more often if you need to.
A good start towards
minimizing disk storage space would be to uncomment the compress option in
/etc/logrotate. conf, so that all the rotated log files are kept compressed.
Avinash
Shenoy is a systems and network administrator at the NCBS, Bangalore,
and Gopi Garge is a technology
consultant with Exocore Consulting <www.exocore.com>