API返回延迟,FPM重启后恢复之后又重现 问题解决方案

泪湿孤枕 提交于 2020-10-02 20:05:54

背景

最近在提供后台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服务,从与上游服务开始建立连接,到接收完响应返回的最后一个字节,所经过的时间。单位为秒
		
        ![](https://img2020.cnblogs.com/blog/385704/202007/385704-20200728162028181-1944819290.jpg
        [参考链接](https://juejin.im/post/5d26eb16f265da1bd522f8d6)

  程序真正的运行时间 = $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 调试
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!