0

We currently have the memory limit set up in Kubernetes for mongo using the below:

    - name: MONGODB_EXTRA_FLAGS
      value: --wiredTigerCacheSizeGB=6

And we verified that it's been parsed with the db._adminCommand( {getCmdLineOpts: 1}) showing it's sent correctly through argv.

However we see the memory usage go up well into 10GB when we have a lot of traffic. Is that normal behavior? Is there another variable that needs to be limited?

1 Answer 1

1

Setting the WiredTiger cache size only limits the memory used for reading and updating documents and indexes in memory (aka the "active working set").

MongoDB server processes will temporarily allocate additional memory as needed for client connections (up to 1 MB per connection) and other server-side processing such as aggregation queries, in-memory sorts, or JavaScript evaluation.

However we see the memory usage go up well into 10GB when we have a lot of traffic. Is that normal behavior?

Yes, more memory usage when you have a lot of traffic should be expected.

You may be able to optimise some of that memory usage with strategies like reducing or removing in-memory sorts, replacing server-side JavaScript with aggregation functions, limiting driver connection pool sizes, or improving your schema to take advantage of schema design patterns and avoid performance anti-patterns. You could also consider reducing your WiredTiger cache size or values like maxIncomingConnections.

Is there another variable that needs to be limited?

The upper limit on resource usage should be determined by your Kubernetes pod or container configuration. Suitable limits to set will depend on your workload, deployment resources, and performance goals.

3
  • 1
    Thank you for the amazing response. I will check out what you linked. For your last note, the initial problem we had and why we added the explicit limit was that Mongo was ignoring the machine memory and resource limit. It might be because we are running 4.4.3 which is a little old and might need to upgrade for it to take those into consideration.
    – Pat
    2 days ago
  • 1
    What is your host O/S for k8s? General support for detecting memory limits within containers was improved in 4.2 (backported to 4.0.9 and 3.6.13) via jira.mongodb.org/browse/SERVER-16571. However, there is a Windows-specific fix in 4.4.4 (jira.mongodb.org/browse/SERVER-52596) and a fix for cgroups v2 on Linux in 4.4.14 (jira.mongodb.org/browse/SERVER-60412). In general I recommend keeping up with patch releases as there are no backward-breaking changes and some very useful stability and diagnostic improvements. The 4.4 series is up to 4.4.17 now :)
    – Stennie
    13 hours ago
  • 1
    We're running it on GKE Container-Optimized OS with containerd (cos_containerd). And thank you for the links. I just checked the change log and the issue we're having was fixed in 4.4.4. Along with some worrying other issues we have yet to encounter. I'll be updating ASAP to 4.4.17 in the next deployment window! :)
    – Pat
    6 hours ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.