[SERVER-30462] Coordinate connection and WT session limits Created: 01/Aug/17  Updated: 08/Jan/24  Resolved: 24/May/19

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

Type: Improvement Priority: Minor - P4
Reporter: Bruce Lucas (Inactive) Assignee: Backlog - Service Architecture
Resolution: Won't Fix Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-30421 mongod "Cannot allocate memory" and c... Closed
Related
is related to SERVER-40161 Make failure of conn->open_session in... Closed
is related to SERVER-40162 Change the default WiredTiger session... Closed
Assigned Teams:
Service Arch
Participants:
Case:

 Description   

Currently

  • the limit on the number of connections is determined by the number of available file descriptors, and we fail gracefully by refusing additional connections if this limit is exceeded
  • whereas the limit on the number of WT sessions is hard-coded at 20000, and we abort if this limit is exceed.

Each connection will require a WT session to do anything useful. So this means that if the maximum number of connections is < 20000 we fail gracefully when this number is exceeded, whereas if the maximum number of connections is > 20000 we may abort when we exceed 20000 connections.

We should either make maximum number of sessions track maximum number of connections, or hard code the maximum number of connections as well.



 Comments   
Comment by Mira Carey [ 24/May/19 ]

Closing this out, assuming that SERVER-40162 mitigates in default configurations, and in favor of SERVER-40161 for a long term solution

Comment by Mira Carey [ 08/Apr/19 ]

bruce.lucas - pinging this ticket with an update:

After SERVER-40162, the wt session limit got a bump up to 33k. I think that should prevent session exhaustion from being the first exhausted resource in most configurations (with file descriptors or processes coming in first, and being non-fatal).

Comment by Mira Carey [ 15/Mar/19 ]

bruce.lucas mentioned

For reference, making failure to allocate a WT session non-fatal was previously proposed and rejected in SERVER-17364.

But after looking through SERVER-17364, it seems we rejected making failure to create a WT session non-fatal back when we used WT sessions for idle cursors. I'm not sure if the same logic applies anymore (SERVER-17364 was re-purposed for that fix).

I'd like storage to reconsider in light of that change.

Additionally, I think we're overthinking a bit in terms of sizing the default limit. If we're actually 1:1 wt sessions and ingress connections / db clients, picking a slightly higher limit (up above 32768), is almost certain to be enough (as we burn a process per client, and I don't think I've seen a user in the wild which changes pid_max)

Opened SERVER-40161 to revisit making session allocation failures non-fatal
Opened SERVER-40162 to consider upping the limit to 33k, to get just beyond some other soft limits

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