Re: Linux Tuning: Objective

George Bonser (grep@shorelink.com)
Sun, 25 Apr 1999 10:21:10 -0700 (PDT)


On Sun, 25 Apr 1999 teamwork@freemail.c3.hu wrote:

> Dear sirs and madams,
>
> After reading a lot of mails regarding tuning Linux to achieve optimal
> performance, there is no argument of our common objective. However, one question
> does come to mind, and it is: In what way should we achieve the objective?

I think this discussion might be better over on the linux-perf mailing
list. Having said that, keep reading.
>
> In other words, what kinds of "products" (for being lack of a better word)
> should this "Linux Tuning" project gives to the Linux community at large?
>
> Should it be a depository of patches?

Yes

>
> Should it be one or more howtos?

Probably ... just make sure they not which kernel versions they cover as
well as the versions of any applications they reference. These kind of
docs get stale quickly as the applications and kernel change.

>
> Should it be a mailing list (linux-perf)
> doing the Q & A style of thing?

That too.

>
> Should it be a web site where people
> can go in and hit the "SCSI" button if
> they want to know if they can tune their
> Linux machine's SCSI devices?
>
> Or should it be all of the above?

There should probably also be some "autotune" tools built.

>
> While we haven't lay down a lot of things for this "Linux Tuning" project yet, I
> believe this is the best time for all of us to come to a consensus of what we
> actually want to do, and how do we achieve it.
>
> Does anyone have any comment on this?
>
> Also, I am including a message I got from the L-K list for those who may've
> missed it.

Ok, let me give an example. I have a customer that wants to compare Linux
against FreeBSD on a web server. I am not a kernel hacker or network
device hacker. The web server will be hit with pretty heavy load.

Which network tweakables should I tweak and which systems tweaks should be
done? I read through the docs on Documentation and there is sparse
information but sparse is a little better than none. My guess is I should
probably change the max window sizes from 64K to 128K and follow the
suggestion that on heavilly loaded systems the ip_local_port_range should
be expanded. What about the system itself, file-max, inode-max ...
probably should kick these up but to what? I would hate for the thing to
fall over in the benchmark test. What about super-max and in kernel,
shmmax. I want enough resources so the thing will get through peak use
without falling over yet I do not want to waste resources either.

I think a more detailed document of the available tweaks in /proc would be
VERY useful.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/