sysctl tuning on Linux

While most Linux Kernels nowadays come with nice sysctl defaults, there’s always room for improvement. Some parameters can be used for performance tuning, others can be critical for security hardening.

What is sysctl?

sysctl is an interface to view and dynamically change parameters in Linux and other *NIX operating systems. In Linux, most of the dynamic Kernel settings can be changed via sysctl. The parameters set by sysctl are also available under the virtual /proc filesystem.

How do I use sysctl?

To read values you’ve two options:

To write values you can use both options again:

However, these parameters are not persistent. You’ve to configure them in /etc/sysctl.conf or /etc/sysctl.d/* if you want them active after a reboot.

Please note that configuration changes will not be detected automatically. You’ve to trigger the reload manually:

Tuning Linux with sysctl

Kernel

To automatically reboot a system after a kernel panic, you can set the following parameter to the amount of seconds to wait before reboot:

Linux Kernels provide a magic SysRq key, which allows the user to perform low-level commands regardless of the systems state. To enable this magic key you’ve to set:

To make sure core dumps will always be written set the following parameter:

It can be useful to have the PID appended on the filename of core dumps. This can be especially useful for debugging multi-threaded applications and it’s easy to setup:

To increase the maximum number of used process IDs you can define the following parameter:

Memory

To tune the memory (VM) behaviour in Linux, you can set some  vm.* parameters.

For example to tell the Kernel how aggressively memory pages should be written to disk (aka swapping), you’ve to change the swappiness value. The higher the value, the more aggressive the swapping:

When you look at filesystems then most of the time some kind of cache is involved. The amount of filesystem cache is based on the percentage of total available memory. To set the maximum amount of filesystem cache can be defined with:

When the defined percentage of memory is reached, then all I/O writes are blocked until enough dirty pages have been flushed to disk by pdflush. This is quite suboptimal because on a healthy system you don’t want to have blocked I/O writes at all. Therefor there’s another parameter, which defines the minimal percentage of dirty memory before the background pdflush process starts to flush out dirty memory pages:

As already described before, pdflush is in charge of flushing dirty pages to disk. So you can optionally change the flush interval by setting the following parameter (in hundredths of seconds, e.g. 500 = 5s):

Of course pdflush needs to know when data can be removed from cache. Sometimes it makes sense to increase the time how long “untouched” data lives be in the cache before it’s marked as expired. Just overwrite the following parameter (again in hundredths of seconds):

If you want to have more informations about the memory on your system, just have a look at:

Filesystem

To increase the maximum amount of file descriptors you can use.

Exec Shield

Exec Shield is a protection against worms and other automated remote attacks on Linux systems. It was invented by Red Hat in 2002. To enable Exec Shield:

Network Core

Some applications are configured for performance and sometimes an application can handle huge buffers. To increase the maximum buffer size for all sockets / connections (this will affect all buffers, e.g. net.ipv4.tcp_rmem) you can use:

When a system is under heavy load and an interface receives a lot of packets, then the Kernel might not process them fast enough. You can increase the number of packets hold in the queue (backlog) by changing:

IPv4

First of all we recommend you tune ICMP a bit. You can do that by ignoring ICMP broadcasts, which will protect you from ICMP floods. We also ignore bogus responses to broadcast frames (violation against RFC1122), so that our log isn’t full of Kernel warnings:

SYN floods are a type of DDoS and can harm your system. To protect from it you should enable SYN cookies, resize the SYN backlog (queue size) and reduce SYN/ACK retries:

To log packets with impossible addresses simply enable:

To disable IP source routing (SRR), so that nobody can tell us which path a packet should take:

By default, routers router everything and even packages which don’t belong to their network(s). To avoid that we’ve to make sure strict reverse path filtering is enabled as defined in RFC3704:

Some applications support higher read and write buffers for sockets. The buffer size parameters are defined by 3 values (min, default, max). To increase the maximum buffer set:

To get better throughput in a network, it might make sense to enable TCP window scaling as defined in RFC1323:

Disable (ICMP) redirects at all. Please note that the send_redirects parameters should be enabled on routers:

Finally disable IPv4 forwarding on non-routing systems:

IPv6

Those who don’t use IPv6 at all should disable it:

If you’re already using IPv6 you might be interested in the following parameters.

On non-routing systems you should disable router solicitations:

You should also don’t accept routing preferences from router advertisements:

Don’t try to learn prefix information in router advertisements:

Don’t accept hop limits from router advertisements:

Disable IPv6 auto configuration, so that no unicast addresses can automatically be configured on your interface from a router advertisement:

If you don’t want your system to be verbose about its neighbours, you should disable neighbour solicitations at all:

Unless you need more than one global unicast address, you should fix the number of assigned global unicast addresses per interface to 1:

.all & .default

A lot of sysctl parameters have several values, because there’s a  .default, .all and sometimes even a .<interface> value. While the  .<interface> value is obvious, you’ve to look closer on the other two.

According to a comment on the linux-kernel mailing list, there’s one major difference:

  • The default value will only be applied ONCE, at the point when an interface is created.
  • The all value will ALWAYS applied in addition.

This means when an interface is created, the default value will be applied to it once. However, you can overwrite that with the interface-specific parameter. The global  .all parameter will always be applied in addition and in the end it depends of the logical operator how the “final value” looks like.

For example there are parameters where all settings need to be 1 (aka  AND), where only one of the settings need to be 1 (aka  OR) or where the highest value will be used (aka MAX).

So it’s important to know that existing interfaces might have a different value than the one you’ve set as default or all.

Where to find documentation?

IMHO the best documentation for sysctl is available directly in the Kernel docs. You can find them in the kernel.org git repository. Just have a look at the Documentation/networking/ip-sysctl.txt and Documentation/filesystems/proc.txt files.

You can also have a look at the man pages on your Linux server. For example if you want to know more about the tcp settings you can run:

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *