[SERVER-60412] Host memory limit check does not honor cgroups v2 Created: 04/Oct/21  Updated: 29/Oct/23  Resolved: 18/Jan/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.2.6
Fix Version/s: 4.4.14, 5.3.0, 5.0.7, 4.2.20

Type: Bug Priority: Major - P3
Reporter: Ayhan APAYDIN Assignee: Amirsaman Memaripour
Resolution: Fixed Votes: 2
Labels: containers, docker, linux, not-fcv, servicearch-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Documented
is documented by DOCS-15043 [Server] Investigate changes in SERVE... Closed
Related
related to SERVER-16571 Use Actual Memory Constraint vs. Tota... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.0, v4.4, v4.2
Sprint: Service Arch 2022-1-24
Participants:
Case:
Story Points: 2

 Description   

As I checked mongoDB gained support for memory constraints over cgroup in linux with SERVER-16571. However it seems that it doesn't have the ability to check memory limit if host is using cgroups v2 resulting hostInfo.system.memLimitMB to be equal to system memory in a containerized environment.

Current code to read memory limits in src/mongo/util/processinfo_linux.cpp

// LinuxSysHelper::getMemorySizeLimit().
.....
std::string cgmemlimit = readLineFromFile("/sys/fs/cgroup/memory/memory.limit_in_bytes");
....

But in cgroups v2 the memory limit is at /sys/fs/cgroup/memory.max.

I think engine should check if the cgroups v2 is enabled on the host and then read the limits according to that.

Tested on mongodb 4.2.6 in docker containers at host Fedore CoreOS 34.20210904.3.0. But I do believe newer versions have the same since source code seems same since first implementation.

 



 Comments   
Comment by Githook User [ 07/Mar/22 ]

Author:

{'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com', 'username': 'samanca'}

Message: SERVER-60412 Support using cgroups v2 to inquire about the memory limit

(cherry picked from commit 6bc31230f0cd0de66f02268c5ce0920c4f27effe)
Branch: v4.2
https://github.com/mongodb/mongo/commit/2c7c06c4defd5f56d9b71225917f28397766aa12

Comment by Githook User [ 07/Mar/22 ]

Author:

{'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com', 'username': 'samanca'}

Message: SERVER-60412 Support using cgroups v2 to inquire about the memory limit

(cherry picked from commit 6bc31230f0cd0de66f02268c5ce0920c4f27effe)
Branch: v5.0
https://github.com/mongodb/mongo/commit/d719e12c3e8a0ae5744e3bd53c27bcffc8e575c4

Comment by Githook User [ 07/Mar/22 ]

Author:

{'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com', 'username': 'samanca'}

Message: SERVER-60412 Support using cgroups v2 to inquire about the memory limit

(cherry picked from commit 6bc31230f0cd0de66f02268c5ce0920c4f27effe)
Branch: v4.4
https://github.com/mongodb/mongo/commit/92e1ac24d775713d07487574ff34039c89171a2c

Comment by Githook User [ 18/Jan/22 ]

Author:

{'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com', 'username': 'samanca'}

Message: SERVER-60412 Support using cgroups v2 to inquire about the memory limit
Branch: master
https://github.com/mongodb/mongo/commit/6bc31230f0cd0de66f02268c5ce0920c4f27effe

Comment by Lauren Lewis (Inactive) [ 12/Jan/22 ]

thanks kevin.arhelger for the follow-up. Spoke w/shameek.ray & we are adding this to our Top Priority Tickets list & will get to it as soon as we can. 

Comment by James H [ 07/Jan/22 ]

Does this issue apply to mongodb 4.4 as well?

Comment by Lauren Lewis (Inactive) [ 16/Nov/21 ]

Flagging for Scheduling, was on the product groomed ticket backlog 2nd in prioritized list.

Comment by Ratika Gandhi [ 25/Oct/21 ]

We should investigate other cgroups v2 changes we will have to make along with doing this ticket. 

Comment by Edwin Zhou [ 14/Oct/21 ]

Hi ayhanap@gmail.com,

Thanks for your bug report. I'll pass this on to the appropriate team for further investigation in a potential improvement.

Best,
Edwin

Generated at Thu Feb 08 05:49:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.