背景
最近在提供后台API时,提供了一个简单逻辑的接口
部署在测试环境，自测没问题，提交测试
突然有一天,接口响应延迟严重，几乎每次都是3-4秒返回
这对于一个接口来说，肯定是有问题的
于是便有了以下的方法尝试
重启FPM
- 最开始以为不是什么大问题，猜想可能是fpm问题
毕竟测试环境，部署代码繁多- 重启后，接口响应正常，可不一会就又复现
重新分析定位问题
- 经过几次的尝试后，发现问题其实没有那么简单
- 重启fpm后，过了不到几秒，问题依然复现
- 编写简单的php文件，无复杂逻辑，只输出字符串，问题复现
- 命令行执行文件，无此问题
- 经过以上尝试，确认是FPM的问题
或者PHP的初始化解析执行的问题，当时想是不是有特定的模块加载
经过php -m 查看，无特殊模块(其实应该仔细看看,所以才绕了弯路)
日志定位
有了上面的分析，最先想到的是利用日志查看问题
查看nginx日志
nginx 日志 格式，添加详细的 各个时间段的相应
log_format main '$remote_addr [$host] - $remote_user [$time_local] $request upstream_response_time: $upstream_response_time
request_time: $request_time upstream_connect_time: $upstream_connect_time upstream_header_time:$upstream_header_time
$status $body_bytes_sent $http_referer $http_user_agent ';
添加了
upstream_response_time
upstream_connect_time
upstream_header_time
含义如下:
request_time
nginx服务，从发起请求的客户端获取到第一个字节开始，到返回给客户端最后一个字节，日志写入文件后，所经过的时间。单位为秒。
upstream_connect_time
nginx服务，从与上游服务开始建立连接，到连接建立成功，所经过的时间。单位为秒。
upstream_header_time
nginx服务，从与上游服务开始建立连接，到接收到响应返回头的第一个字节，所经过的时间。单位为秒。
upstream_response_time
nginx服务，从与上游服务开始建立连接，到接收完响应返回的最后一个字节，所经过的时间。单位为秒
程序真正的运行时间 = $upstream_header_time - $upstream_connect_time
$request_time 中包含了数据返回时间
$request_time 中包含了日志打印的时间
nginx 日志显示
xxx [xxx] - - [11/Jul/2020:13:36:45 +0000] POST /xxx/xxx HTTP/1.1 upstream_response_time: 3.048 request_time: 3.048 upstream_connect_time: 0.000 upstream_header_time:3.048 200 98 - Dalvik/2.1.0 (Linux; U; Android 8.1.0; vivo 1808 Build/O11019)
从中可以看出确实是 上游服务FPM 返回延迟了
配置 FPM 慢日志
lowlog = /xxx/www-slow.log request_slowlog_timeout = 1s
发现 慢日志中，并没有记录
于是怀疑是否 日志文件权限有问题，修改后依然未写入
想到用sleep的方式，写入慢日志，成功写入
现象就是 配置了1秒的FPM慢日志，接口响应超过1s，但没有写入慢日志
那就说明 PHP 程序执行完成后，又做了什么处理，导致了延迟
或者 其他的配置问题
文件描述符
网上搜索, 可能是 文件的打开数量有限制, 并没有做优化
于是 查看对应的配置
nginx 配置文件 worker_rlimit_nofile
ulimit -n
是做了优化的的
也并不是网上所说的问题
思考
- 所有的PHP程序响应都有延迟，超过3s左右
所以并不是个例，和其他的如mysql redis 连接没关系
- 突然间出现的，原来是没问题的，应该是近期做了更改
但由于测试环境，东西太多，一时也找不到是什么改动
- 命令行模式下，没有延迟，所以和FPM有关
而重复FPM后,几秒内正常,后又复现
一直以为是FPM配置有什么问题,目前看并不是
- 所以肯定是 程序处理完成后，又做了什么，导致了延迟
那有什么办法可以追踪代码的执行吗
对于php而言，xhprof扩展 是可以很好的展示一个流程中的耗时
而且还有对应的图片展示(需要安装扩展)，但还需要安装
于是就有了下面的方法
strace调试跟踪
简单来说，strace是用来跟踪进程内的系统调用和接受的信号。
对程序调试很有帮助
- 于是,来调试FPM的进程，看看都做了哪些调用
strace -t -f $(pidof php-fpm| sed 's/([0-9]*)/-p 1/g') -epoll -o /tmp/strace.txt
打开文件
12406 06:55:13 poll([{fd=5, events=POLLIN}], 1, 5000) = 1 ([{fd=5, revents=POLLIN}])
12406 06:55:13 poll([{fd=6, events=POLLOUT|POLLWRNORM}], 1, 10000) = 1 ([{fd=6, revents=POLLOUT|POLLWRNORM|POLLERR|POLLHUP}])
12405 06:55:16 --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=12401, si_uid=0} ---
12405 06:55:16 +++ exited with 0 +++
12401 06:55:16 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=12405, si_status=0, si_utime=0, si_stime=0} ---`
- 通过以上信息，在 06:55:13后，确实有超过3秒的时间，是 fd=6 导致的, 那 fd=6 是什么
可通过 lsof -p pid 的方式查看
但 进程id 12405 退出了
就是说，由于FPM的动态启动进程的配置，一个进程退出后，会重新生成进程，已达到配置的进程数
所以 一边打印调试信息，一边输出 工作pid的 文件信息
- lsof -p 12408
php-fpm 12408 apache 5u IPv4 1203792101 0t0 TCP localhost:cslistener->localhost:22384 (ESTABLISHED)
php-fpm 12408 apache 6u IPv4 1203794606 0t0 TCP xx.com:28866->ip-10-66-100-169.ec2.internal:9411 (SYN_SENT)
此时，原因终于找到了,在每次结束后，又请求了某个ip 9411端口的服务
可以看到tcp状态是 SYN_SENT，虽然已发出连接请求，但对应没回应，并不是ESTABLISHED状态
说明是对应请求机器的问题
于是去查看此ip对应机器,原来确实有此机器，但不知什么时候起，此机器已下架了
导致了这个问题，此刻想到了为什么突然之间接口就有延迟了
问题修复
既然确认了是连接了某个服务导致的问题，对应的php配置文件应该有配置
于是 找到 所有模块配置文件ini路径，搜索ip
发现是 其 molten 扩展配置
molten 扩展是一个全链路追踪的工具
molten追踪php核心调用库运行时信息并且按照zipkin/optracing格式输出信息。
可以追踪curl,pdo,mysqli,redis,mongodb,memcached这么多的运行信息。
去掉此扩展加载，重启FPM后，接口响应正常
总结
- 问题出现的时候，最直观的方式应该是日志，通过查看日志，可以解决大部分问题
- 当日志解决不了的问题，如何调试，就成了问题解决的关键
strace ltrace 以及 gdb 调试