[SERVER-40162] Change the default WiredTiger session_max from 20k to 33k Created: 15/Mar/19  Updated: 08/Jan/24  Resolved: 06/Apr/19

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: 4.1.10

Type: Bug Priority: Major - P3
Reporter: Mira Carey Assignee: Gregory Wlodarek
Resolution: Fixed Votes: 1
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-30462 Coordinate connection and WT session ... Closed
is related to SERVER-40161 Make failure of conn->open_session in... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage NYC 2019-04-08
Participants:
Case:

 Description   

The current default wired tiger session_max limit is 20k. Unfortunately, this can often put session creation as the first terminal failure when adding many live connections.

Since we currently use a thread per connection, and the vast majority of users don't alter pid_max, pushing the limit up to 33k is likely to make thread exhaustion the first limit users hit, instead of the wt session limit. Thread exhaustion has slightly nicer semantics in that failure to create threads for ingress connection handling is non-terminal.



 Comments   
Comment by Githook User [ 06/Apr/19 ]

Author:

{'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'}

Message: SERVER-40162 Change the default WiredTiger session_max from 20k to 33k
Branch: master
https://github.com/mongodb/mongo/commit/32b7f6e8004a05d6245c41302e706137e9f28b2f

Comment by Mira Carey [ 21/Mar/19 ]

I think a reasonable deployment of mongod will set ulimits high enough that file descriptor exhaustion will not be a problem.

In that configuration, the first thing that will fail (as you add concurrent running connections to a mongod), can be session creation, due to to the session_max limit. The form of that error is an abrupt fassert.

If we were to up the default as suggested by this ticket, we'd be more likely to hit thread exhaustion (as almost no users in the wild set pid max past 32k). Thread exhaustion in the server can be fatal, but usually is not (generally the thread we fail to allocate is the worker thread to handle a connection, and we error in that case by closing the incoming socket). From what I've gathered, I think that users prefer that failure mode.

There's an explicit comparison between this ticket and SERVER-40161. If we were to tackle that ticket, there would be no need to do this on. If were to do this ticket, the urgency on that one would lower.

Comment by April Schoffer [ 21/Mar/19 ]

mira.carey@mongodb.com can you give us any more insight into the priority / how important this is?

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