I was wondering what do you usually change in the kernel configuration. I am having make menuconfig in front of me right and now I need to prepare the best kernel ever for my new shiny servers. I use sources from linux-image-2.6.32-5-amd64 Debian Squeeze package because unfortunately kernel.org is still down.

Now, I see a lot of modules inside. Most of them I don't need but it's just an additional code loaded to the kernel on demand. No big deal.

On the other hand I have a lot of options that could improve performance and which are very useful on the server with hunders of services and users. For instance preemption, timer frequency/dynamic ticks or SMT Hyperthreading. Sometimes disabling these features is better, eventually.

Also there are many options I don't know how they affect system behaviour or simply I do not understand. (Like, what the hell is Cryptographic API? I never had idea if I need it or not.)

If you could write few wise words I would really appreciate.

4 Answers 4


A few wise words? OK: If you do not know, Do Not Touch.

How about a few more words?

The default/generic kernels shipped with any modern Linux or BSD variant are fairly well-tuned for the vast majority of workloads. Most of what you might need to touch is accessible through sysctl knobs (or on Linux /proc/sys tunables), and you'll find advice on changing those from various vendors, usually geared toward specific situations.

Mucking about with the kernel configuration, or the tunable parameters, without a clear understanding of what you're doing and why you are doing it is a path that leads straight to nightmares: Unbootable systems, abysmal performance, "this solution works for everyone else but not me" situations, etc.

Unless you have specific reasons why you need to change kernel configuration or tunable parameters, and have researched to gain a thorough understanding of what you are adjusting and why it's the right thing to do you're probably better off with the defaults for now.

  • 2
    @ahes tune it for what? Like votetaq just explained, most general workloads are taken into consideration in the generic kernels. If you have a very specific workload that you want advice for, you need to give more details.
    – MDMarra
    Oct 6, 2011 at 22:23
  • 1
    IMHO if you have a custom built kernel for each machine you're doing it wrong. If you have a custom kernel for your environment (one kernel that runs on every piece of hardware and has been tuned based on your workload) you're doing it right. Beyond that if you're at a point where you need to tune the kernel the people whose opinions you want are kernel developers. We may have a few hanging around...
    – voretaq7
    Oct 6, 2011 at 22:25
  • 1
    @ahes ?..what workload. It's not a hard question to answer. "better performance" and "hundreds of users with shell access" is not the description of a workload.
    – MDMarra
    Oct 6, 2011 at 22:27
  • 4
    @ahes, I think that you will find that the vast majority of sysadmins don't try to do that kind of micro-optimization. When we see someone asking about this it is almost always a sign of premature optimization, or a person trying to optimize the wrong thing. User-land application code is almost always a bigger source of performance issues.
    – Zoredache
    Oct 6, 2011 at 22:49
  • 2
    "What do (I) usually change in my kernel configuration?" - absent a very specific requirement, Absolutely Nothing. This is probably the answer you're going to get from any competent sysadmin, and is especially true on Linux, where the distribution vendors provide security patches/updates for the kernel as binary packages. Like @mailq said, each subquestion you asked in the comment could easily be a Ph.D thesis. Many of them have been the subject of USENIX papers, and a few have whole books written on them.
    – voretaq7
    Oct 7, 2011 at 1:43

As voretaq7 mentioned, the stock kernel is fine for most people.

If you really think that you must modify the kernel from the distributions default, then you almost certainly need to start by devising a testing system that will simulate your typical usage.

Then you should start testing settings one at a time. You should almost certainly start your kernel experimentation by taking a copy of the existing kernel configuration /boot/config-2.6.32-5-amd64 and tweaking it from there. If you are on a Debian/Ubuntu system, then you should use make-kpkg to build your kernels. This will give you a debian package with the kernel, modules, and scripts required to easily install it.

If you don't understand what something does, then you are in luck, you have the source code and documentation right there, it is part of the linux source. All you have to do is start reading it.


I'd like to suggest that you are asking the wrong question, ahes.

I would counsel that you start with these two questions:

  1. What kinds/aspects of performance are important to you?
  2. How will you measure and trend these as accurately as possible?

You can't really 'tune' something that has no 'gage' attached to it, primarily becuase without a gage, you can't accurately tell whether you're tuning in the right direction or the wrong one, until you've gotten drastic results. And far too often, by the time you are in 'drastic' territory, things are drastically wrong.

Determining and prioritizing the kinds/aspects of performance you want to optimize for is important, too. Often, we rob Peter to pay Paul - that is, we tune specifically for one sort of performance, knowing full well that this optimization can harm other types of performance. As a simple example, sometimes we must optimize a server for cost and thus give up some reliability. Or we might choose a RAID configuration that optimizes for reads but in the doing, gives up some write performance.

Once you can really measure the things that matter, you can more accurately and objectively define the performance numbers you want to hit, and you can see when they are slipping. And knowing that, you can follow up with the next set of questions, which essentially summarize to: how can I get these specific numbers back into the range where I want them to be? With your performance gages in place, you'll be able to make small changes one at a time, and see clearly whether those changes are helping or hurting.

There is no 'one size fits all' answer; no checklist of well-known parameters every sysadmin should instantly tune to eleven. It's situational, and it's usually a slowly moving target.

I wish you good fortune in your project, whatever it may be.

This one goes to eleven!

  • Nice answer :) I really enjoyed it.
    – ahes
    Oct 6, 2011 at 23:42

Sorry I can't see the gain in your work.

Let's assume you invest 8 hours of work to find out each parameter and make comparisons between each self-built-kernels which one makes it "faster". Then you will probably gain a performance improvement of 1%. How much does your boss have to pay for this work? Can't you just buy more hardware for the same amount to gain a performance improvement of 8%?

  • Hehe. If I had a boss and he would pay me €100 per hour it is still €800. I don't think you can buy a decent hardware for that. Anyway, I made a 20% boost on mail servers farm last time. :)
    – ahes
    Oct 6, 2011 at 23:37
  • Someone pays you. And let it be your clients. And you shouldn't buy new hardware but buy better hardware in the first place.
    – mailq
    Oct 6, 2011 at 23:40
  • You are saying that it is better to buy the newest hardware than optimize you system? :)
    – ahes
    Oct 7, 2011 at 0:01
  • Yes, this is what I say. Hardware is cheap. Manpower is expensive. If you want to optimize then do it in user space but not in kernel space.
    – mailq
    Oct 7, 2011 at 9:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.