背景
最近遇到一個問題，很煩，真的很煩。無緣無故在你吃麻辣燙的時候有臺機器就告警，突然它用不了。當然，幸好我們提供的服務集群，一個干不了活，可以用其他來干。但即使這樣，我還是很煩告警。
收到的告警是：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
域名解析www.test.com出現問題
直接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<<- opcode: QUERY, status: NOERROR, id: 1269
;; 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都沒有問題，那么會不會程序出問題了。
我使用了的業務接口 ，假設www.a.com/api ，并且創建了一個純凈的www.a.com/test.php. (腳本里面就一個echo)
訪問www.a.com/test.php，查看php-fpm拉起的UDP端口數：
ss -anup|grep php-fpm|wc -l
0
是0啊，好像沒有問題。
ss -anup|grep php-fpm|wc -l
1
再訪問一次www.a.com/api:
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也會因此減少，這當然只是個輔助方案。
