[DOCS-11746] Wrong swappiness configuration recommendation Created: 29/May/18  Updated: 30/Oct/23

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Bug Priority: Major - P3
Reporter: Ricardo Lorenzo Assignee: Ravind Kumar (Inactive)
Resolution: Won't Do Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to DOCS-10405 Add swappiness>0 recommendation to pr... Closed
Participants:
Days since reply: 1 year, 14 weeks, 2 days ago
Epic Link: DOCSP-1769
Story Points: 0.1

 Description   

I have found today that the official recommendation is to set vm.swappiness to 1.

I do believe this is a serious misunderstanding of the purpose of the swap space. Apparently, the documentation was worse (set to 0) as I can see on DOCS-10405.

From the official Linux documentation you can read the following:

The casual reader^1^ may think that with a sufficient amount of memory, swap is unnecessary but this brings us to the second reason. A significant number of the pages referenced by a process early in its life may only be used for initialisation and then never used again. It is better to swap out those pages and create more disk buffers than leave them resident and unused.

The swap usage is not a problem by itself. The only problem which may affect performance is if the operating system is actively paging in and out which can be tracked using vmstat.

You can find many articles in relation to this subject:

https://chrisdown.name/2018/01/02/in-defence-of-swap.html

In the previous documentation ticket, the value of 10 was suggested which is better than 1. However, I would not recommend changing anything unless you really know what you are doing and you have the tools to observe the behavior and the impact.

 

Scope

Based on internal discussions, we're going to remove this recommendation until performance testing completes and we have more data to back any recommendations in one direction or another. We will backport this removal to 3.6.



 Comments   
Comment by Education Bot [ 31/Oct/22 ]

Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you!

Comment by Henrik Ingo (Inactive) [ 24/Jan/19 ]

I didn't want to suggest more than one alternative, but for the record, I am not against removing this recommendation entirely.

Comment by Bruce Lucas (Inactive) [ 10/Jan/19 ]

if some other thing suddenly uses up more memory than you would expect, mongod can end up getting killed by the OOM thread

Not to mention if mongod itself uses much more memory than expected, and there are a number of known reasons this can happen.

However it seems debatable to me whether it's better to start paging and run really slowly for a long time, or fall over and restart quickly in this scenario.

Comment by Henrik Ingo (Inactive) [ 09/Jan/19 ]

I believe Atlas tested Ricardo's recommendation on the smaller instances, but "felt" that if anything, it made things worse.

Cailin said this in an email once. I'm intentionally not pinging her, as she probably has more important things to focus on today. But someone could ask Cloud team about this at a later time.

Generated at Thu Feb 08 08:03:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.