[SERVER-2554] Make listen backlog configurable Created: 15/Feb/11 Updated: 06/Dec/17 Resolved: 24/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking |
| Affects Version/s: | 1.6.5 |
| Fix Version/s: | 3.5.13 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Roger Binns | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Done | Votes: | 4 |
| Labels: | platforms-re-triaged | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Ubuntu 64 bit 10.10 using 10gen stable package |
||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | Linux | ||||||||||||||||
| Sprint: | Platforms 2017-09-11 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
The socket listen backlog is not configurable. I have a situation where a large number of worker processes receive work notification from outside of Mongo and then all simultaneously connect to mongo get more details. They overwhelm the listen backlog and consequently some get connection refused. Most daemons let you configure the listen backlog size away from the normal OS default of 5. |
| Comments |
| Comment by Ramon Fernandez Marina [ 24/Aug/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': u'acmorrow', 'name': u'Andrew Morrow', 'email': u'acm@mongodb.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 08/Aug/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
thestick613 - I see what you are saying. I'd missed that SOMAXCONN was hard coded to 128 on Linux. Given that setting a high listen value has a real cost, it seems that it really would be best to make this configurable, and have it default to SOMAXCONN. Note that any such configuration would still only be able to raise the listen limit to whatever broader limit was imposed by the system. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tudor Aursulesei [ 08/Aug/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tudor Aursulesei [ 08/Aug/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
db version v3.4.6 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Eric Sommer [ 08/Aug/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
thestick613, which dot release of 3.4 are you currently using? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tudor Aursulesei [ 07/Aug/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hello, this is actually still present in 3.4, as you can see from this strace. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 07/Aug/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
thestick613 - Could you please let me know what version of MongoDB you are running where you observe this? We actually believe this issue was fixed in MongoDB 3.4 as part of | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tudor Aursulesei [ 06/Aug/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This should also be merged into mongos. Port 2000 is where i run my mongos
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tudor Aursulesei [ 21/Jul/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
What is the status of this? I sometimes get [Thu Jul 20 23:57:46 2017] TCP: request_sock_TCP: Possible SYN flooding on port 30001. Sending cookies. Check SNMP counters. After i get this message, the mongod instance gets very unresponsive and i need to restart it to get things back to normal. I haven't yet figured out if it gets syn-flooded by a replica set or by the application. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Roger Binns [ 12/Dec/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
To my knowledge there is no way to make it adaptive (ie not need configuration). You can look at the rate of incoming connections, but you can't tell when a connection initially arrived (ie how long it was in the listen queue before accept was called). You also get no notification whatsoever about the connection requests that were rejected because the queue was full. (You could in theory see how long something was in the listen queue if you also had a network tap and looked at the TCP headers and understood the operating system behaviour with regard to TCP timestamping. However this is orders of magnitude more code and considerably more fragile than an integer option.) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Eliot Horowitz (Inactive) [ 12/Dec/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The goal is to have as few options as needed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Roger Binns [ 12/Dec/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The limit is still a problem for me. Once more worker machines come online I'll be having the listen length issue again. All of my worker processes (not threads due to Python GIL) talk to MongoDB. I end up with over 1,000 connections to MongoDB and all of those happen at startup virtually instantaneously (lots of forks). I'm rather sceptical that one size will fit everyone hence a need for it to be configurable. There is a reason why virtually every UNIX daemon that will serve non-trivial loads has it as a configurable, and rarely use the OS default of 5. As an example something else I use is gearman which takes --backlog and a default of 32. MySql takes --back_log and I don't know what the default is. I don't run postgres so I can't tell what it does, but I did find a CVS commit from last year making the listen backlog configurable. So it is evident that other databases and similar system components had the need to make the value configurable. What makes using MongoDB so special that its default is the perfect value for everyone? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Eliot Horowitz (Inactive) [ 11/Dec/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The reason its open is to figure out if we should make it configurable. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by John Zwinck [ 11/Dec/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Isn't it already set to 128? I did the archaeology and found this which seems to be the original code calling listen(2) four years ago, with a backlog of 128: https://github.com/mongodb/mongo/commit/5ab9ae9d47df7fb32e6dd95b404e783020281218#grid/message.cpp So, is this bug valid? Does it refer to something I'm not seeing? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Roger Binns [ 15/Feb/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
128 would certainly have fixed the issue for me. However it is traditional that the number is configurable (command line flag) since it is unlikely one number fits all circumstances. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Eliot Horowitz (Inactive) [ 15/Feb/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We could just raise it to 128. |