MongoDB memory usage on Windows Server 2012 R2

[Vladimir Temelkovski]

I have two production servers running Windows server 2012 R2. As a primary and secondary server, they are used for a failover scenario, where the if one fails, the other will take the load.

My application is using MongoDB replication. I have 3 instances. Primary and arbiter (which i'm going to move it on a different server, this is just a temporary souliton) and a secondary node on the secondary server.

After a time, the RAM consumption is becoming very high on both servers. MongoDB takes all the available RAM usage and does not release it. I have noted this behaviour only when the MongoDB is working in a replica.

I have done some research, and found out that it is not possible to limit the RAM usage of the mongod process itself. I'm little sceptic with MongoDB using all the RAM.

Windows Resource Manager has been deprecated in Windows Server 2012 R2.

Please share your experiences, thoughts or ideas how to limit the RAM usage of the mongodb process on my windows server.

 rs.status()"set": "XXXXXX",
"date": ISODate("2015-03-03T13:35:39.000Z"),
"myState": 1,
"members": [
    {
    "_id": 1,
    "name": "Server1:3000",
    "health": 1,
    "state": 1,
    "stateStr": "PRIMARY",
    "uptime": 67557,
    "optime": Timestamp(1425389739,
    19),
    "optimeDate": ISODate("2015-03-03T13:35:39.000Z"),
    "electionTime": Timestamp(1425322202,
    1),
    "electionDate": ISODate("2015-03-02T18:50:02.000Z"),
    "self": true
    },
    {
    "_id": 2,
    "name": "Abritrer1:3001",
    "health": 1,
    "state": 7,
    "stateStr": "ARBITER",
    "uptime": 67547,
    "lastHeartbeat": ISODate("2015-03-03T13:35:38.000Z"),
    "lastHeartbeatRecv": ISODate("2015-03-03T13:35:39.000Z"),
    "pingMs": 0
    },
    {
    "_id": 3,
    "name": "Server2:3000",
    "health": 1,
    "state": 2,
    "stateStr": "SECONDARY",
    "uptime": 67542,
    "optime": Timestamp(1425389737,
    26),
    "optimeDate": ISODate("2015-03-03T13:35:37.000Z"),
    "lastHeartbeat": ISODate("2015-03-03T13:35:37.000Z"),
    "lastHeartbeatRecv": ISODate("2015-03-03T13:35:38.000Z"),
    "pingMs": 1,
    "syncingTo": "Server1:3000"
    }
],
"ok": 1
}

[Will Berkeley]

What version of MongoDB is this? What storage engine are you using, if the version if 3.0? Is the high memory consumption causing the mongod process to be oom killed? It's expected that mongod with the mmap storage engine will use more and more memory if the workload is touching more and more of the data and bringing it into memory, but that memory can also be released by the OS if it's needed for other things. Can you show us the mem subdocument from the output of db.serverStatus()?

I'm guessing that the memory usage is higher when you create a replica set because the synchronization between the servers is causing all the data to be loaded into memory.

-Will

[Vladimir Temelkovski]

Hi Will, thanks for the reply.

I'm using mongo 2.6.3

Here is the MEM sub-document from the requested output:

"mem" : {

        "bits" : 64,

        "resident" : 750,

        "virtual" : 91005,

        "supported" : true,

        "mapped" : 45402,

        "mappedWithJournal" : 90804

The mongo is not releasing memory. Hence it is "suffocating" the OS causing it to crash.

Regards,

Vladimir

[Dwight Merriman]

it is normal with the mmap storage engine (the only engine in v2.6) for it to use all available -- i.e. free memory.  that engine uses memory mapped files.  it then allows the OS virtual memory manager to manage the memory.  if another process needs RAM, it should yield it.  

to really see this i think you would need to use the windows resource manager or perfmon -- the mem status in mongodb is just telling you what was memory-mapped, not what is actually in ram, i believe.  the resident number is a "real" number but -- it is not too high?

how is the box crashing?

p.s. the above says conceptually the numbers make sense -- however there could be bugs that are windows specific.  check jira.mongodb.org.  there might even be fixes that are in the 2.6 branch and after 2.6.3.  why not try the latest 2.6 regardless if you are having a problem?  depending on your situation, you could try 3.0 and the wildtiger storage engine too, but that is quite new i think that's a good idea if you have time to test your app with it, but i wouldn't change that on a whim in a production system without planning as for example, one db operation might be 60% faster and another 10% slower, things like that you would want to verify performance by the use case.

[Vladimir Temelkovski]

Hi Dwight,

Thanks for your response.

The box crashes by suffocating (not allowing RDP connections due to low RAM) and eventually become not responsive. .

Unfortunately Resource manager for WIndows Server 2012 r2 has been deprecated: technet.microsoft.com/library/hh831568.aspx

In order to change the version I would need a solid proof that this will fix the issue. We are trying to simulate the situation on test environment, but since there is a process that is constantly connected to an API and pulling data, I cannot intercept this process since it is highly important that it does not be interrupted.

The only question i can think of is could the queries be the problem? Could some query optimization fix the problem.

Thanks.