>The people reading the faq are not the people who need custom kernels.
>Those people *know* what they need and are not deterred. But as
>always, when we try to help the userbase by offering the advice they
>need, someone needs to chime in and muddy the waters. So now some dude
>is going to read your email and conclude that he can get better mysql
>speed on his 1gb box by shaving a driver. You're not doing anyone any
>favors.
>And no, we cannot assume that people correctly self identify when they
>are special. Ignorant people don't know they are ignorant. But at
>least some of them read the faq. So at least let them get the best
>answer for them.
I agree that a user without a good reason shouldn't mess
with kernel modification. The default settings as provided
are very usable in -almost- every situation.
A factual essay with some detail about better approaches
to improving system performance might be the following.
Of course, it should be edited appropriately if it were
to be used, examples added or deleted, and any good
warnings added to the "what not to do" section.
(this is cc: to tech@ as a possible extension of the FAQ, etc,
if deemed useful)
<html>
<body>
<h2>Improving system performance</h2>
<p>The best approach is:
<h3>Inspect your system</h3>
Intelligently observe
what your system is doing using the many monitoring and profiling
utilities provided with the system to see where time is being spent
and what resources are insufficient.
Examples of these utilities are: ps, vmstat, iostat, gprof, etc.
<h3>Correct wasteful applications</h3>
<p>In most cases, the system monitoring utilities will show a hot
spot - one program is using far more resources than it should.
Very often the same work can be done using a better algorithm,
a more efficient utility, or work can be removed without affecting
the desired results.
<h3>Correct kernel usage</h3>
<p>
The kernel itself is almost never the problem:
if it appears so, the applications you are running
are issuing large numbers of syscalls or other
behavior which causes the kernel to do work.
Correct that behavior before blaming the kernel.
<code>ktrace</code> is an example of a monitoring program which will record
all interaction between a program and the kernel.
<h3>Upgrade I/O devices</h3>
<p>
If your applications are being starved
and monitoring shows either large interrupt times in the kernel
or large idle times when applications should be running,
look at your peripherals.
Old or inefficient I/O devices
can make your system run slowly because the kernel
must do very large amounts of work to make them run or user
applications must wait a very long time for data.
Examples are: NE2000-style or other non-DMA network interfaces,
slow disks or disk controllers which don't do DMA,
USB 1.0 devices, etc., etc.
A newer network card or disk is often the most cost-effective
way to increase performance by large amounts for very little money.
<h3>Improve memory use or add memory</h3>
<p>
If your system is paging excessively you need to use memory better.
<p>
Most modern systems have many megabytes of memory. The kernel
only needs a few [a minimum number, like 8?] megabytes to run.
All the other memory is available for applications and disk buffers.
If memory demand is too high, profile and monitor your system
for applications hogging memory.
<h3>User environment tuning</h3>
<p>There are many ways to make applications run faster which
are not necessarily obvious.
These are examples which have been useful in the past:
<p>If programs referencing temporary files are slow,
placing <code>/tmp</code> and <code>/var/tmp</code> on drives other
than the one with user data being used can sometimes give large speedups.
Directing small, transient temporary files to a memory file system, or piping
data between applications on multiprocessor or multicore systems can
sometimes greatly increase performance.
<p>If disk I/O is a bottleneck reading very large files, increasing the
cluster size of the file system where the large files reside can improve
performance, as long as there is sufficient physical memory to hold large
disk buffers and the increase in wasted space for small files is acceptable.
This requires backing up the file system, destroying it, and recreating it
with the new parameters.
Be absolutely sure data are backed up and recoverable
before doing this!
<h3>Kernel tuning</h3>
<p>There are a number of kernel parameters which can be tuned if your
monitoring shows very specific performance bottlenecks.
For instance,
network performance with long fast pipes can sometimes be improved by
increasing the default socket buffer allocations.
Other networking parameters such as TCP SACK window size can be
tuned if you are very familiar with TCP low-level details.
NFS performance can sometimes be improved by increasing the number of
NFS I/O threads.
<p>
These should not be done unless you can show why with network
statistics and tcpdump output - you can also cause many problems
which are very hard to diagnose by tweaking the wrong parameter.
<h2>What not to do</h2>
<h3>Don't blindly optimize</h3>
<p>Optimizing without factual data from real applications
inevitably wastes time and effort.
It often makes things worse.
<h3>Don't mess with the kernel</h3>
<p>
Removing drivers or other sections of the kernel
is a desperation measure to fit a system onto
a platform which is too small and cannot be upgraded.
<p>
Removing drivers will not make your system run faster.
Drivers which are not attached to a peripheral consume
zero CPU time. Drivers which are attached to peripherals
which are inactive use zero or a trivial amount of CPU
time.
<p>
Removing drivers will not reclaim significant memory.
The maximum amount reclaimable is a megabyte or so.
There are many easier ways to use what memory you have
more efficiently.
<p>
Removing drivers will confuse any attempt to debug any problems
with your system. The first thing anyone will say to you is:
<br>
<b>Reproduce this problem with a standard release kernel.</b>
</body>
</html>
