[SERVER-27927] Maximum thread cache byte limit should change based on number of connections Created: 06/Feb/17  Updated: 27/Oct/23  Resolved: 18/Dec/17

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.4.2, 3.5.2
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Andrew Young Assignee: Mark Benvenuto
Resolution: Works as Designed Votes: 0
Labels: tcmalloc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Platforms 2018-01-01
Participants:
Case:

 Description   

Currently, a mongos instance will attempt to cleanup memory from a thread's cache during threadStateChange() if the thread's cache size is larger than 10,000 bytes. This number was chosen heuristically based on having no more than 1,000 clients connected to a mongos instance. If there are more than 1,000 clients, then the cleanup code is run far more often. This is also problematic as the mongos logs a debug message every time the cleanup is performed.

The suggested improvement is to adjust the maximum thread cache size value based on the number of currently active client connections.

The code that this change relates to is located in https://github.com/mongodb/mongo/blob/r3.4.2/src/mongo/util/tcmalloc_server_status_section.cpp#L68-L86



 Comments   
Comment by Mark Benvenuto [ 18/Dec/17 ]

TCMalloc already dynamically adjusts the individual thread sizes, and ensures a minimum of 512KB per thread. There are not plans to adjust the thread cache based on the number of threads in MongoDB.

In 3.6, we have disabled markThreadIdle by default so the messages will not be logged.

Comment by Eric Milkie [ 06/Feb/17 ]

We should also consider calling BecomeTemporarilyIdle(), which was added recently to TCMalloc and is intended to do what we need here, rather than calling MarkThreadIdle() and MarkThreadBusy().

Generated at Thu Feb 08 04:16:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.