Last Modified: Sep 13, 2023
Known Affected Versions:
11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4
12.1.0, 11.6.1 HF1
Opened: Jul 14, 2015 Severity: 3-Major
sessiondump opens a TCP connection to TMM. It really only needs to make one connection, but it was actually making one connection for each request. This is visible in a packet capture or by monitoring the number of sockets left in TIME_WAIT state On a box that had 1000 sessions, a little over 1000 sockets were generated by the sessiondump call: # netstat -a | grep memcache | grep TIME_WAIT | wc 3 18 267 # sessiondump --allkeys 1> /dev/null # netstat -a | grep memcache | grep TIME_WAIT | wc 1054 6324 93806
The extra connections have a minor throughput impact, because of the cost of establishing TCP 3WHS. The more important impact is that on a large system (around 20k sessions or more), this will be creating a lot of sockets in a very short period of time. These sockets go into TIME_WAIT and are not immediately reusable. The box could run out of sockets and sessiondump will exit.
This issue is most relevant when BZ511900 is present. That fix improved sessiondump performance by eliminating the amount of process forking. The connection reuse problem isn't really a visible problem until after that. BZ 511900 was included in 12.0 BZ 533422 (this bug) was included with 12.1 So relevant to all 12.0 customers and to 11.x customers that request a hotfix with BZ 511900
The sessiondump utility now reuses the TCP connections.