The Linux kernel is optimized so that it can perform generic tasks and work well with an average workload without any modification out of the box, however you can optionally further optimize and tweak various kernel runtime parameters to increase the performance level, allowing you to squeeze out as much performance as possible.
Here we’re going to discuss the /proc/sys file system and how you can modify kernel runtime parameters to modify and tune Linux.
Notes and warnings
This post only scratches the surface of system optimization and kernel parameter modification by dealing with the more commonly modified parameters, as this is a requirement for the RHCE certification. Red Hat offer an entire course/exam dedicated to system performance tuning, for further information see here.
It’s also important to note that you should first perform changes to kernel runtime parameters on a test server first. These can also be applied in a non persistent manner first (which we will discuss) allowing you to easily revert any changes with a system reboot should anything go horribly wrong. Once applied you would want to make sure that you perform adequate testing to confirm that the change works as intended prior to making the change persistent.
Making a single change at a time and performing in depth testing on each change can help you determine what individual settings are actually doing, compared to changing many things at once, potentially at random, which could result in negative results. Basically if you don’t know what you’re changing you should perform some research first and not change anything you’re unsure of unless on a test server that you don’t mind breaking and playing with.
About the /proc file system
The /proc/sys file system contains files that represent the current state of the kernel through a number of values that have been set on various parameters which do different things. As this gives us an interface to the Linux kernel, we can apply changes to optimize and finely tune specific settings. The /proc file system is virtual which is why everything is listed as 0 bytes, and changes made to files will not survive a system reboot.
We can view the current settings of all system parameters by running the ‘sysctl -a’ command, as shown below there are 1008 different tunable variables on my RHEL 7 system.
[[email protected] ~]# sysctl -a | wc -l 1008
We also need to note that net.ipv4.icmp_echo_ignore_all and /proc/sys/net/ipv4/icmp_echo_ignore_all are equivalent, the ‘.’ can be changed to ‘/’ to refer to the full path of the file within the /proc/sys file system.
Modifying Kernel Runtime Parameters
The values in the /proc/sys file system can be modified a few different ways which will either persistently remain after a system reboot, or will only apply non-persistently and will revert back to default after a system reboot.
Non persistent changes
For instance let’s take a look in the /proc/sys/net/ipv4/icmp_echo_ignore_all file below.
[[email protected] ~]# cat /proc/sys/net/ipv4/icmp_echo_ignore_all 0
This file currently contains ‘0’, which means off. A ‘1’ on the other hand would mean that the setting is on and enabled. By default icmp_echo_ignore_all is set to 0 so the system will respond to ping.
We can manually set this value to 1 instead which will disable ping responses, this can be done by simply running an echo command as shown below to overwrite and replace the content of the file with a 1 rather than a 0.
At this point you should start up a constant ping to your test machine and watch it respond, once we change this parameter to ‘1’ the pings should start to fail.
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
After performing this command, the system should no longer respond to ping requests.
This can also be done with the sysctl -w command, as shown below. These essentially perform the same result, that is modifying the file in /proc/sys.
sysctl -w net.ipv4.icmp_echo_ignore_all=1
Both of these methods are non-persistent and will not survive a reboot. If you perform either the echo or sysctl -w commands and perform a system reboot, the change will not stay and the value of the parameter that you set will revert back to the default setting.
In order to have the change remain persistent and survive a system reboot, we need to create a .conf file within the /etc/sysctl.d directory. This file will be read by the systemd-sysctl service on boot as well as other sysctl configuration files. Prior to RHEL 7 this was typically done by modifying the /etc/sysctl.conf file, however as of RHEL 7 you should create your own “*.conf” files within the /etc/sysctl.d directory for this purpose.
If we want to ignore all ICMP echo requests persistently we can create a file with any name in /etc/sysctl.d as long as it ends in .conf – this is important for the file to be picked up and used.
[[email protected] ~]# echo "net.ipv4.icmp_echo_ignore_all = 1" > /etc/sysctl.d/icmp-ignore.conf [[email protected] ~]# cat /etc/sysctl.d/icmp-ignore.conf net.ipv4.icmp_echo_ignore_all = 1
In the above example we have created the /etc/sysctl.d/icmp-ignore.conf file which contains “net.ipv4.icmp_echo_ignore_all = 1”, on the next system reboot the /proc/sys/net/ipv4/icmp_echo_ignore_all file will be set to 1, rather than the default of 0.
We don’t need to perform a reboot to apply the changes, we can apply the changes by simply using sysctl -p, as shown below by running this net.ipv4.icmp_echo_ignore_all is set to 1
[[email protected] ~]# sysctl -a | grep icmp_echo_ignore_all net.ipv4.icmp_echo_ignore_all = 0 [[email protected] ~]# sysctl -p /etc/sysctl.d/icmp-ignore.conf net.ipv4.icmp_echo_ignore_all = 1 [[email protected] ~]# sysctl -a | grep icmp_echo_ignore_all net.ipv4.icmp_echo_ignore_all = 1 [[email protected] ~]# cat /proc/sys/net/ipv4/icmp_echo_ignore_all 1
With the ‘sysctl --system’ command we can view all changes in all sysctl configuration files, our persistent /etc/sysctl.d/icmp-ignore.conf file will show here as well as anything else applied.
[[email protected] ~]# sysctl --system * Applying /usr/lib/sysctl.d/00-system.conf ... net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 kernel.shmmax = 4294967295 kernel.shmall = 268435456 * Applying /usr/lib/sysctl.d/50-default.conf ... kernel.sysrq = 16 kernel.core_uses_pid = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 fs.protected_hardlinks = 1 fs.protected_symlinks = 1 * Applying /etc/sysctl.d/99-sysctl.conf ... * Applying /etc/sysctl.d/icmp-ignore.conf ... net.ipv4.icmp_echo_ignore_all = 1 * Applying /usr/lib/sysctl.d/libvirtd.conf ... fs.aio-max-nr = 1048576 * Applying /etc/sysctl.conf ...
The /etc/sysctl.d/icmp-ignore.conf file is the only one that we have manually added for our change, all of the other files and directories are default.
If you have been running a constant ping to your test system, you will have noticed that it will have stopped responding to ping any time /proc/sys/net/ipv4/icmp_echo_ignore_all contained a ‘1’, and would have responded while this contained a ‘0’.
While our example has only specifically covered icmp_echo_ignore_all, the method of modifying other kernel runtime parameters works in the same way. Here are some other commonly modified parameters that are important to be aware of, especially for RHCE.
- kernel.hostname – This sets the hostname of the system.
- vm.swappiness – This defines the value that represents the willingness of your system to swap data out from main memory to disk.
- net.ipv4.ip_forward – This must be enabled in order for your Linux system to act as a router and forward traffic between network interfaces.
You should now have a brief understanding of the /proc/sys file system and the kernel parameters available which can be modified to change various aspects of Linux system behaviour. We can change settings in a non-persistent manner for testing by changing the content of the virtual file within /proc/sys, or we can create our own .conf file within the /etc/sysctl.d directory which will then persistently apply the change even over a system reboot.
This post is part of our Red Hat Certified Engineer (RHCE) exam study guide series. For more RHCE related posts and information check out our full RHCE study guide.