What reasonable value of swappiness should I config to get better performance?
In the process of optimizing the Android system, the configuration of the ‘swappiness’ value is crucial. The value path is
/proc/sys/vm/swappiness. Some sources suggest setting it to 60, while others recommend setting it to 120. Some sources state that its maximum value is 100, while others claim it is 200, which confuses me.
How can I confirm the maximum value supported in my system?
Links I can find on Stack Overflow:
The maximum value of
swappiness is 100 on kernel version before 5.8, and this value was increased to 200 on kernel 5.8.
If you carefully read the answers in your linked (and there are tons of other similar questions and articles to be found in google), you’ll see that none of them provide the best value. It depends on the exact workload and its specific behavior on the machine you’re running the OS, and it just requires some benchmarking.
Usually the default value (60) is the most balanced one.
Though the answer in your link explain how
swappiness affects the system, I’ll try to make it simpler, without the calculations and the numbers that other add to their answers that make them more precise but maybe a little more difficult to read.
If you want the gist of it in extremely simplified manner (just for the sake of making it more intuitive), you could say your RAM holds two primary types of pages:
- Anonymous pages, which is just the "regular" memory used by processes. This is the memory used for process dynamic data such as variables.
- File-backed memory, or Page Cache (I won’t get into the difference). This is used to cache files from a disk in the memory. Usually the cost of reading a file directly from the disk is pretty high, so usually the kernel saves the data it read from the disk in its Page cache, so the next time you read data from this file, it will be satisfied directly from the RAM, and you won’t need to access the disk again. This extremely accelerate reading files from disk.
When there’s a high memory pressure, and the kernel needs to free some space in the RAM, it faces a difficult decision:
- Should it clear the File-backed memory? This clears the memory really fast for new pages, but than if you access the file again you will need to read it again from the disk, which is costly.
- Should it swap-out some anonymous pages? Maybe there are some inactive pages that haven’t been used for a long time and maybe wouldn’t be needed by the process for a long time, so it’s better to write it to the swap and keep the file cache in the memory to save additional I/O?
swappiness is what hints the kernel what it should prefer. A value of "0" tells the kernel to avoid swapping out anon pages as much as possible, and to always clear the file-back memory/cache to make more space. The more you increase it, the more the chances are your anon memory would be swapped out and file-backed memory is favored. On kernels > 5.8, a value of 200 means it should always prefer to swap out anon pages and keep the file-backed memory in the RAM.
That’s why the recommended value depends on many different factors, such as the workload type, the I/O speed and the swap speed.
- For servers that run databases, it’s commonly recommended to reduce the swappiness to 0, because it’s crucial the DB would be able to keep all the data in the RAM to ensure high performance.
- If you perform a lot of I/O and your disk is relatively slow, you might prefer increasing the
swappinessto possible reduce I/O, if your processes have a lot of inactive memory pages that they probably won’t use.
- On machines that are using
zswap, where the swap is compressed and stored in a dedicated section in the RAM (instead of the disk), the cost of swapping is even lower, so maybe it’s ok to favor swapping over clearing file data from the RAM.
- On machines that are using
But the bottom line is: There’s no general recommended value. For the standard case and workloads, the default value should be fine. If you see too much swapping, or too much I/O, you might want to carefully tune the value, but you’ll have to test it. Just change the value and check how it impacts the performance of the machine until you reach a state that suits your specific machine and workload best.