线程 链接时间太长 php-fpm,PHP-FPM拉起过多UDP连接导致域名解析失败

背景

最近遇到一个问题，很烦，真的很烦。无缘无故在你吃麻辣烫的时候有台机器就告警，突然它用不了。当然，幸好我们提供的服务集群，一个干不了活，可以用其他来干。但即使这样，我还是很烦告警。

收到的告警是：Unknown: php_network_getaddresses: getaddrinfo failed: Name or service not known

这个提示很熟悉，显然是DNS解析出现问题了。

检查

业务中很多地方用到域名访问API，尝试取一个redis域名测试，用www.test.com代替实际域名。

dig排查下问题：

dig www.test.com

dig: isc_socket_bind: address in use

直接dig一下：

dig

dig: isc_socket_bind: address in use

域名解析有问题，但是该dns服务在其他机器上没有问题。

使用tcp协议查询(dig默认是使用udp)：

dig www.test.com +tcp

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> www.test.com +tcp

;; global options: +cmd

;; Got answer:

;; ->>HEADER<

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;www.test.com. IN A

;; ANSWER SECTION:

www.test.com. 6 IN A client_ip

;; AUTHORITY SECTION:

www.test.com. 6 IN NS www.test.com.

;; Query time: 2 msec

;; SERVER: ip#port(ip)

;; WHEN: Wed Aug 30 20:47:28 CST 2017

;; MSG SIZE rcvd: 83

tcp出去是ok的。说明udp有点小问题

telnet测试redis服务：

Trying ip...

Connected to ip.

Escape character is '^]'.

说明redis服务没问题。

ping测试，提示：

connect: Resource temporarily unavailable

我ping了在其他机器上可以ping通的域名，但这台机器出现该提示，我找了资料，Linux文档提示服务器监听队列已满后，客户端会报连接拒绝错，就可能出现该错误。所以dns解析过程会不会也是因为这个问题引起的呢？

上面一系列检查，得出假设：很有可能是udp连接出现问题，可能是服务器端口占用过多，导致域名解析失败，因为域名走udp协议。

进一步验证

ss -anul|wc -l

28237

这个参数确实有点多。

再看下udp端口范围：

cat /proc/sys/net/ipv4/ip_local_port_range

32768 61000

61000 - 32768 = 28232 < 28237

果然端口号不够用，所以造成之前的问题。

看看是什么东西占用大量的UDP端口号：

ss -anulp|head -n50

UNCONN 0 0 *:36756 *:* users:(("php-fpm",pid=16546,fd=72))

UNCONN 0 0 *:36757 *:* users:(("php-fpm",pid=16173,fd=54))

UNCONN 0 0 *:36758 *:* users:(("php-fpm",pid=16307,fd=60))

UNCONN 0 0 *:36759 *:* users:(("php-fpm",pid=16414,fd=65))

UNCONN 0 0 *:36760 *:* users:(("php-fpm",pid=16093,fd=69))

原来是php-fpm！！作为世界上最好的语言怎么能出现这种问题呢！！好气啊！

追查问题根源：

是不是php-fpm配置问题

那么问题来了？为何php-fpm会拉起这么多的udp连接，我很是不解。脚本程序中没有使用udp的地方呀？一开始我以为是php-fpm配置有问题，害我把php-fpm的对子进程的管理方式以及相关配置改了个遍，验证一段时间后还是出现这个问题。

是不是nginx配置问题

所以不是php-fpm配置的问题，那会不会nginx配置问题，但理论上nginx只做一个转发，不会造成这种现象。对nginx的参数进行调优测试，也是用默认的nginx配置测试，在一段时间后，服务器还是会报错。

是不是程序的问题

既然niginx和php-fpm都没有问题，那么会不会程序出问题了。

我使用了的业务接口 ，假设

访问

ss -anup|grep php-fpm|wc -l

0

是0啊，好像没有问题。

ss -anup|grep php-fpm|wc -l

1

ss -anup|grep php-fpm|wc -l

2

再访问一次！

ss -anup|grep php-fpm|wc -l

3

我擦，问题就在这里！！

于是迅速定位了这个api，查到了某个可疑的扩展，是一个第三方扩展，将其屏蔽，再次访问，没有占用任何udp端口。

我重新改写和编译了该扩展，这个问题就得到解决，一个php-fpm子进程最多占用一个udp端口(之前的一个php-fpm会占用几十乃至更多的端口，造成端口不够用)。

总结

表象：PHP-FPM拉起过多的UDP端口，一直占用，导致dns无法解析，而业务中需要访问域名，所以出现了问题。

根源：第三方扩展使用了UDP，会不停地创建线程，api是不会回收相关线程的连接句柄。导致UDP端口过多，导致UDP在机器上的其他服务不能用。

解决方法：第三方扩展的不停创建线程和不释放句柄修改掉。不放心的同学可以写一个crontab，查询UDP session，如果超多一定数量(用ss，会币netstat快一些)，那就平滑重启php-fpm，隔一段时间执行。

tips：如果访问量不是很大，php-fpm.conf配置中可以使用pm=ondemand模式拉起子进程，其中的pm.process_idle_timeout = 10s；设置会在空闲的时候，会平滑关闭worker，这样你的UDP session也会因此减少，这当然只是个辅助方案。