New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Linux Kernel Optimizations and Tricks + I/O schedulers
Hello LET,
I'm in the progress of compiling some linux kernels for my KVM LEBs with grsecurity; When it comes to optimizations however, I am quite clueless as to what should be done and there aren't much resources out there...
What are some tricks/optimizations that you usually do, and why do you do it (benefits for websites, etc)? eg. enable tickless system (dynamic ticks) for game server hosting.
Edit: Also, outside of the kernel, it'll be interesting to see what I/O scheduler fits best for your use case. (CFQ/anticipatory/deadline/noop)
It'll be interesting to see what tricks everyone has up their sleeves.
Comments
That's because there is no need to optimize a kernel, or even compile one for that matter. Using a kernel you compiled yourself does not make you a special little snowflake.
Optimize the software you're running; not the kernel.
I need to patch up the kernel with grsecurity (custom settings) to begin with, so not compiling a kernel is out of the question.
You should always set the scheduler to noop inside your VPSes (Xen/KVM), because there's already a scheduler on the host node, and running the same alghorithm twice (or even two different ones over each other) only makes things worse; noop usually gives a very nice I/O boost.
Also I love Xen/KVM due to the fact I can run the absolutely latest kernel versions (3.7.1 currently), and the new kernels are generally just faster and better than older ones -- especially compared to OpenVZ where everyone is stuck with that ancient 2.6.18/2.6.32 crap.
That's a great idea and explanation! I've only had noop set on SSDs in physical servers, but I never thought of setting them on VPSes. I'll definitely go ahead and change the them right now.
For a Debian kernel these defaults can be changed.
Unselect Optimize for size if you're happy with a larger kernel which will be faster.
Processor Family - change this to match your cpu .
Maximum number of cpu's reduce this from 32 to match the number of cores you have - just saves some memory. Or increase it if you have more than 32 cpu's.
Preemption model - change to No forced preemption (Server).
noop is a good idea. If the host has write caching protection (BBU, etc), you can do barrier=0 or nobarrier in /etc/fstab for a mounting option. noatime is another good mounting option.
Unselect Optimize for size if you're happy with a larger kernel which will be faster.
Processor Family - change this to match your cpu .
Maximum number of cpu's reduce this from 32 to match the number of cores you have - just saves some memory. Or increase it if you have more than 32 cpu's.
Preemption model - change to No forced preemption (Server).
I'll try that out; what are the pros+cons for disabling forced preemption in a LAMP environment?
I use grsecurity mainly for additional chroot security, and to prevent users from seeing other users' processes. In that case, grsecurity is probably fine for my use case? I'll have a read on Hardened Gentoo. Thanks for the input!
Outside of VMs, would you say it is safe to do barrier=0 on the node itself? (assuming it has a hardware raid card with a bbu) also, what are performance gains of doing so?