LINUX Max Socket Connections Queue

[Jojo Castro]

Hi all....

Can someone help me how to determine max socket connection queue in Linux?

Thanks!

[Matti_Kurkela · Accepted solution]

There are two sysctl parameters, documented in the Documentation/networking/ip-sysctl.txt file of the Linux kernel documentation package.

These parameters are visible as files in /proc/sys/net, and root can directly write new values to them to make changes immediately, and/or use /etc/sysctl.conf to make the changes persist through system reboots. Please see also "man sysctl".

----
/proc/sys/net/ipv4/tcp_max_syn_backlog:

Maximal number of remembered connection requests, which are still did not receive an acknowledgment from connecting client.

Default value is 1024 for systems with more than 128Mb of memory, and 128 for low memory machines. If server suffers of overload, try to increase this number.

/proc/sys/net/core/somaxconn:
Limit of socket listen() backlog, known in userspace as SOMAXCONN.
Defaults to 128. See also tcp_max_syn_backlog for additional tuning for TCP sockets.

----

In /etc/sysctl.conf file, you're supposed to omit /proc/sys from the beginning of the parameter pathnames and replace all slashes with dots. So, in /etc/sysctl.conf, these parameters should be expressed as:

net.core.somaxconn
net.ipv4.tcp_max_syn_backlog

MK

[Jojo Castro]

Hi Matti, this is a very informative anwers.
One more thing, would you know how i can monitor the usage?

[rick jones]

I'm not sure if Linux exports an interface to see the pending connection backlog on a specific socket.

BTW, the actual limit may be lower than those sysctls depending on what the application passes-in on a listen() call.

PPS - these are queued/pending connections, not a limit to the total number of sockets (connected or otherwise) in the system.

[Jojo Castro]

Thanks Ricky.

Actually, server being investigated is a postgre application system that has too many connections.

This server already rebooted for 4-6 times for the past 5 days and we have been seeing too many TIME_WAIT, CLOSE_WAITs status via netstat.

Our developer is currently looking at the connection parameters that we could tune on the server.

Not sure if related to the following messages seend on /var/log/messages

[root@`hostname` log]# grep segfault messages*
messages:Nov 30 18:48:52 SPCC1 kernel: sshd[8228]: segfault at 0000000000000000 rip 00000000002842dc rsp 00000000ffffd05c error 4
messages:Nov 30 21:30:33 SPCC1 kernel: sshd[19165]: segfault at 0000000000000000 rip 00000000002842dc rsp 00000000ffffd05c error 4
messages:Nov 30 23:56:35 SPCC1 kernel: sshd[25822]: segfault at 0000000000000000 rip 00000000002842dc rsp 00000000ffffd05c error 4
messages:Dec 1 09:42:06 SPCC1 kernel: sshd[7869]: segfault at 0000000000000000 rip 00000000002842dc rsp 00000000ffffd05c error 4
messages:Dec 1 12:55:05 SPCC1 kernel: sshd[13884]: segfault at 0000000000000000 rip 00000000002842dc rsp 00000000ffffd05c error 4
messages:Dec 3 17:38:27 SPCC1 kernel: spcc_core.exe[27857]: segfault at 0000007fc6de5b20 rip 0000000000409d3a rsp 0000007fbff7d450 error 4
messages:Dec 4 08:31:15 SPCC1 kernel: sshd[24187]: segfault at 0000000000000000 rip 00000000002842dc rsp 00000000ffffd05c error 4

[rick jones]

"Ricky" - not sure how to respond to that one... :) Anyhow, what is your definition of "too many" TIME_WAIT connections? Ditto re CLOSE_WAIT

I could see where an sshd dying would leave behind a TIME_WAIT - in theory the kernel will close all the file descriptors when the process dies and TIME_WAIT is there to protect new connections with the same "name" (local/remote IP, local/remote port) from inadvertently accepting old, delayed segmnets from previous connections. That would be doubplebpluungood as it can lead to silent data corruption.

CLOSE_WAIT though is the state TCP enters when it has received and ACKed the remote's FINished segment and is now waiting for the local side to call close() or shutdown(). From "our" perspective a CLOSE_WAIT connection is a simplex connection where we can send data to the remote, but the remote will not be sending us data. The remote in this case should be in FIN_WAIT_2.