How critical is disabling of Transparent Huge Page

[Darshan Shah]

In my setup, I do not have the ability to disable Transparent Huge Page setting.

For that matter, neither can I set vm.overcommit to 0.

Also, I do not have the access to mount the disks using "noatime" option.

In light of this situation, I wanted to figure out how critical are these settings to get a very good performing MongoDb installation?

Thanks!

[Stephen Steneker]

Hi Darshan,

Transparent Huge Pages (THP) and other settings as advised in the production notes (http://docs.mongodb.org/manual/administration/production-notes/) are recommendations to ensure best performance. The impact of these settings will vary depending on your environment and workload, but if you are unable to change them in your deployment this is probably a moot point. If possible, I would ask if your system administrator is able to make these changes on your behalf.

For some more information on possible impact of THP, see: https://jira.mongodb.org/browse/DOCS-2131.

Regards,

Stephen

[Darshan Shah]

Hi Stephen,

Browsing the forums, I did see a few issues that could be attributed to THP & vm.overcommit but I am not sure whether those are rare or definitely bound to occur in a critical production environment.

The reason for asking this question is that in case we definitely need THP disabled and vm.overcommit set to 0 for achieving good performance, I can explore options like using virtualization to achieve this or perhaps even dedicated boxes only for MongoDb.

I looked at Docker as a way to achieve this but it does not support disabling THP or setting vm.overcommit on a container basis, so I will look into other virtualization technologies to see if it can be done using them.

Please let me know your thoughts.

Thanks.

[Stephen Steneker]

On Wednesday, 14 October 2015 00:20:36 UTC+11, Darshan Shah wrote:

Browsing the forums, I did see a few issues that could be attributed to THP & vm.overcommit but I am not sure whether those are rare or definitely bound to occur in a critical production environment.

Hi Darshan,

THP has definitely been attributed to a few performance issues, but the impact is deployment and workload specific rather than a guaranteed problem. If you want to proactively ensure your environment is tuned as best as possible, you should try to implement all of the relevant recommendations in the MongoDB production notes.

Since THP is enabled by default in many recent Linux distros, recent versions of MongoDB do include a startup warning if THP appears to be enabled. As I mentioned, see DOCS-2031 for more details that might be helpful to check (search for "red flags" in that issue for some common signals).

The reason for asking this question is that in case we definitely need THP disabled and vm.overcommit set to 0 for achieving good performance, I can explore options like using virtualization to achieve this or perhaps even dedicated boxes only for MongoDb.

I looked at Docker as a way to achieve this but it does not support disabling THP or setting vm.overcommit on a container basis, so I will look into other virtualization technologies to see if it can be done using them.

 

For a critical production deployment I would consider more traditional virtualization or dedicated options ahead of Docker at the moment. In my opinion, the network configuration and coordination required for a multi-server Docker deployment (eg. a replica set or sharded cluster) currently requires significantly more effort to set up and manage.

The Docker ecosystem is definitely evolving quickly to address multi-container/multi-host dependencies, but many of these tools are still in beta (i.e. Docker Machine/Swarm). You'll have to make your own evaluation on whether the current level of maturity is a good fit for your production deployment & timeline.

Regards,

Stephen

[Dwight Merriman]

if your db is larger than RAM it will likely be a big probably at least with the mmap storage engine.

if your db fits in RAM, it might work fine.

with the wildtiger storage engine, it might work ok with huge pages, but i don't know the answer so that it something to investigate if you need it.

anyway you could be empirical and just do some representative perf test scripts on the environment and see if you get the results you want; but given the situation i would definitely test wildtiger in addition to mmap (WT is not default in v3.0 but it is there and is production/stable.)  

[Darshan Shah]

Thanks for this input - will check it out - most probably the dataset should fit in the RAM.

We are still exploring stuff so I do not have a clearer picture of the possible PROD environment and what results to expect.

Can you please provide some links to get me started with the perf tests you mentioned?

Realized just now that I didn't make it clear:

The reason why I cannot change these settings is that MongoDb is co-located with another application which requires different setting of these values.

That was the main reason to look at Docker / Virtualization.

Thanks

[Dwight Merriman]

by perf tests i meant just write a short script in your favorite programming language, or even the mongo shell javascript as a program, that does operations similar to what you will be doing in your real app.  this is what i usually do as an off the shelf benchmark won't be representative for a particular use case necessarily.  good luck with your project.