Modifying /etc/sysctl.conf and achieving persistence for vm.min_free_kbytes

[Robbie]

It has been pleasing to see Synology incorporate more sensible values for vm.min_free_kbytes in later versions of DSM. Two of my 3 NASes have what I consider reasonable values set as default, so no longer need editing. For the third I would like to increase the value from 65536kB to 131072kB (I have 32GB of RAM).

However, I am having considerable difficulty setting a persistent value by editing /etc/sysctl.conf. I can add the extra parameter and value ok and running a sysctl -p does load and activate it but the new value does not survive a reboot. The new value does remain in the modified /etc/sysctl.conf but post-reboot the value shown in sysctl -n vm.min_free_kbytes reverts to the original. It is if the sysctl.conf file is not being read during boot.

root@R:~# sysctl -n vm.min_free_kbytes
65536
root@R:~# vi /etc/sysctl.conf
root@R:~# sysctl -n vm.min_free_kbytes
65536
root@R:~# sysctl -w vm.min_free_kbytes=131072
vm.min_free_kbytes = 131072
root@R:~# sysctl -p
kernel.panic = 3
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
vm.min_free_kbytes = 131072
root@R:~# sysctl -n vm.min_free_kbytes
131072
root@R:~#
# Post-reboot...
root@R:~# sysctl -n vm.min_free_kbytes
65536
root@R:~# cat /etc/sysctl.conf
kernel.panic = 3
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse  = 1
vm.min_free_kbytes = 131072
root@R:~# sysctl -n vm.min_free_kbytes
65536

Does anyone know how to make a persistent change to the vm.min_free_kbytes value?



️

 

[jeyare]

following your procedure, I did not find anything that should be kept in normal condition after each reboot
but it isn't the first time when I have read, that /etc/sysctl.conf wasn't used during the reboot

another way how to do it:
- enter a repetitive Task within the DSM Control panel
- trigger is the boot of the NAS
- use yours:

sysctl -w vm.min_free_kbytes=131072

and enjoy

-- post merged: 9. Mar 2022 --

ofc, reboot the NAS

 

[Robbie]

@jeyare - Thank you, although I was trying to avoid adding it as a script to Task Scheduler to avoid the config 'double-take' moment at boot.

It is of course the exact method Synology Support pushes out when users have the issue and know enough to complain about it. Presumably the recent updates mean less customers run into these issues now but I am surprised (well, not that surprised) that Synology did not make the value a bit more dynamic for those who go on to expand the RAM.

I do wonder how many put up with the slight stutters, hesitations or even hangs and just accept it as normal when it is such an easy thing to overcome.

If DSM really is ignoring the sysctl.conf at boot I wonder where they are pulling the settings from for sysctl itself?

Anyway, still hopeful that someone will know how to force a persistent change via the CLI.

️

 

[jeyare]

I don't want to take your idea for a pro-grade solution (which I prefer also), but the problem with the default state of the /etc/sysctl.conf after the reboot has been known at least since 2015 (as I know)

If DSM really is ignoring the sysctl.conf at boot I wonder where they are pulling the settings from for sysctl itself?

the answer to this question may be known to the person who created it, but it is possible that he no longer works in the Syno

but you can create a ticket to Syno support

 

[Robbie]

Well at least Synology did improve the base settings, so there is that.

In the interim I have added the command to the root/boot script.

Rob@R:~$  sysctl -n vm.min_free_kbytes
131072
Rob@R:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          32072         843       16074         110       15154       30546
Swap:          2047           0        2047
Rob@R:~$

️