5 ms·
Additionally, a TCP connection is essentially an operating system resource; you need to set aside a port and space for a send and receive buffer. It might seem
by bwross 12y ago
Additionally, a TCP connection is essentially an operating system resource; you need to set aside a port and space for a send and receive buffer. It might seem fine for a client to open hundreds connections, but imagine being a server with thousands of clients all opening hundreds of connections to you. You very quickly run out of resources and either have to close connections or reject new connections.
- otterley 12y agoThat hasn't been a practical problem in many years. Most servers have gigabytes of RAM and a 64-bit kernel nowadays.
- getsat 12y agoLinux starts to act weird around 200,000 concurrent connections in my experience, even with aggressive sysctl tuning. You end up with weird edge cases like netstat literally taking 15 minutes of CPU time (in kernel) before it dumps the list of connections to stdout. Not sure about FreeBSD or any other OSes.
- btmorex 12y agoNot saying netstat isn't slow, but: # time sh -c 'netstat -tn | wc -l' 486206 real 0m13.538s user 0m1.698s sys 0m10.380s It still works with a whole lost of connections. (in fairness, only about 130k were connected)
- getsat 12y agoThe problem is that it doesn't scale linearly. There's some O(n4) algorithm being used in netstat or some kernel syscalls or something. Once you go over 250k, things get _really_ weird.
- patrickmcmanus 12y agotry ss -nt instead.. it uses netlink sockets instead of /proc and generally scales much better
- getsat 12y agoThanks for the tip!