[SERVER-901] Severe memory leak in mongos on simple queries Created: 03/Feb/10  Updated: 12/Jul/16  Resolved: 05/Feb/10

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 1.3.5

Type: Bug Priority: Critical - P2
Reporter: Ilya Martynov Assignee: Eliot Horowitz (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 9.10, i386


Attachments: File valgrind.log     File valgrind.log    
Participants:

 Description   

Mongos seems to leak on every findOne query.

How to reproduce? I've configured sharding using example script: http://github.com/mongodb/mongo-snippets/blob/master/sharding/first.js
I ran this script once and then tried to benchmark query time using the following code in the client:

for (i = 0; i < 400; i ++) { for (num = 0; num < 100; num ++) { db.data.findOne(

{"num" : num}

) }; } 1;

When running this code I noticed mongos quickly grows in size in memory. Restarting client doesn't seem to release any memory resources in mongos. I could reproduce it first with mongodb 1.2.0, then I tried 1.2.2, 1.3.1 and finally with the latest git and all versions showed the problem. I'm sorry, I'm not sure how mongodb version number maps to version number of mongos so I've set only latest release and unreleased version numbers in jira's selection box but I guess it probably affects all versions.

P.S. I've tried to run mongos under valgrind and it confirms the problem. See the attached valgrind log.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 05/Feb/10 ]

the others look ok for me for now.
resolving

Comment by Mathias Stearn [ 05/Feb/10 ]

I've plugged the large (2.6GB!) memory leak. The remaining small leaks are either for std::string which valgrind says to ignore and for various mongo caches. Some of the cache leaks may simply be "leaking" by design since there is little reason to free them when mongos exits and their container is destroyed.

Reassigning back to eliot for input on the caches. The largest leak (1.6MB) seems related to the TODO in the CursorCache destructor. The updated valgrind.log I uploaded should be more useful since mongos was compiled without inlining.

Comment by Mathias Stearn [ 05/Feb/10 ]

Updated valgrind log with debug version of mongos

Comment by auto [ 05/Feb/10 ]

Author:

{'login': 'RedBeard0531', 'name': 'Mathias Stearn', 'email': 'mathias@10gen.com'}

Message: Plug large memory leak in mongos SHARDING-77
http://github.com/mongodb/mongo/commit/a39d197a5aa996569d39d073a973a690fde11296

Generated at Thu Feb 08 02:55:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.