HTTP部分时候请求长时间卡死超时问题排查思路

部分业务方用户反映有些时候hue刷新页面会卡死2-5min无响应。个人也遇到过几次，在页面访问卡住的同时，通过curl url:8890 -I -L一样会卡住无法返回页面内容。

通过记录事故时间点反查linux TCP相关信息，发现在卡死的时刻，TCP connection数量骤增到2-3k (ss -s)，同时TCcpExt的ListenDrops和TcpExt.ListenOverflows会相对较高：

此时感觉是因为sysctl中关于TCP连接的部分参数没有优化导致，所以添加了如下参数并重启了hue服务，但问题依旧。

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_fin_timeout = 10

net.ipv4.tcp_keepalive_time = 1200

net.ipv4.tcp_max_syn_backlog = 65535

net.ipv4.tcp_max_tw_buckets = 400000

net.ipv4.tcp_orphan_retries = 1

net.ipv4.tcp_retries2 = 5

net.core.netdev_max_backlog = 512000

net.ipv4.tcp_syn_retries = 3

net.ipv4.tcp_synack_retries = 3

net.ipv4.tcp_slow_start_after_idle = 0

vm.min_free_kbytes = 360448

vm.zone_reclaim_mode = 1

net.core.somaxconn = 65535

#net.netfilter.nf_conntrack_max = 1655350

#net.netfilter.nf_conntrack_tcp_timeout_established = 7200

#net.netfilter.nf_conntrack_tcp_timeout_time_wait = 10

kernel.shmall = 4294967296

kernel.shmmax = 68719476736

kernel.msgmax = 65536

kernel.msgmnb = 65536

此时想关注下到底是哪个进程导致了TCP连接数骤增，ss -n后发现主要为:50010端口。netstat -nlp | grep :50010后发现是DataNode服务。

此时通过dmesg发现如下报错内容：

[12522087.589828] TCP: request_sock_TCP: Possible SYN flooding on port 50010. Sending cookies.  Check SNMP counters.

[12547933.126955] TCP: request_sock_TCP: Possible SYN flooding on port 50010. Sending cookies.  Check SNMP counters.

也即TCP连接已经全被50010吃满了，导致新来的hue请求无法正常建立connection导致用户角度的卡死和超时（参考：https://help.marklogic.com/Knowledgebase/Article/View/182/0/possible-syn-flooding-messages-in-system-logs）。

同时，通过sar -n DEV 3发现下行带宽已经占了1.2GB/s, 已经达到机器对应的最大下行带宽，所以数据传输不出去也是可能的因素之一。

最终，将混部的服务拆分到独立的节点，问题解决。