Messages in this thread | | | Date | Sun, 25 Apr 1999 10:21:10 -0700 (PDT) | From | George Bonser <> | Subject | Re: Linux Tuning: Objective |
| |
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/
| |