使用 Swoole-Tracker 秒级定位 PHP 卡死问题,真香

上述代码通过$condition控制循环退出，如果程序验证不严格，某些情况$condition永远为真就会导致请求卡死。

2.sesstion_start函数导致卡死

PHP的 session 锁等待(ps:很多地方叫做session 死锁 ，这不太符合死锁定义)，这个相信大部分PHPer都遇到过，PHP默认会把session信息存储在/tmp/sess_下面的session文件里面，调用session_start()函数的时候会调用flock系统调用给session文件加锁，如果前一个请求没有结束或者手动释放session就会导致后面的请求无法获得锁，卡死在session_start()这个地方。下面举个例子，比如这种代码：

 setInterval( function  () {
    $.post("/ ajax /doSomething", {}, function (result) {//1s进行一次ajax
         });
}, 1000)//1000ms == 1s
  

前端js定时通过ajax请求一下后端PHP的接口(/ajax/doSomething)做一些比较耗时的事情，写代码的人可能想当然的认为第一次的请求即使没有处理完，也不会影响第二次的请求，因为有很多的 fp M进程每次请求会分发到不通的进程，但殊不知第二次请求会卡死在session_start()。

3.flock函数导致卡死

最常见的场景就是写日志，在PHP代码中确保每次fwrite写的日志内容小于8k的情况下我们可以利用append原子追加方式写日志，但是如果保证不了小于8k我们就需要在每次写日志前给文件加文件锁来避免两次日志间产生穿插的情况，代码如下：

 lock _UN);    // 释放锁定
}
  

如果在A进程获得锁后由于某种问题阻塞了那么B进程就会卡死在第三行flock的位置，除非A进程被kill掉，系统会自动释放这个文件锁

4. 网络客户端未设置超时时间

MySQL、CURL、Swoole\Client 等网络客户端未设置超时可能会导致进程阻塞。Swoole\Client 建立 TCP 连接的时候 connect 方法的最后一个参数是超时时间，-1即为永不超时，注意这里设置不是单指这次connect方法，而是后面所有的send, recv 都永不超时，在同步阻塞的编程模式下，如果此时对端机器直接宕机等原因导致网络不通，那么本端业务的表现就是卡死状态，所有的send,recv方法都将被阻塞，代码如下:

 connect('127.0.0.1', 9501,-1)) {
      $cli->send("data");
      $cli->recv();
} else {
      echo "connect failed.";
}
  

5. Swoole协程的lock

在 Swoole 协程模式下，不正确的使用lock也会导致所有协程大面积卡死，如下代码，通过go方法创建2个协程(不理解协程的同学可以理解为创建了2个线程)，第一个协程lock获得锁后在co::sleep位置让出了cpu此时开始执行第二个协程，第二个协程会卡死在第6行获得锁的位置，同时第一个协程也永远无法恢复继续执行。

 lock();//获得锁
        Co::sleep(1);//让出cpu
        $lock->unlock();//释放锁
    });
}
  

如何发现卡死

上述只是举了一些例子，真实业务中还有各种姿势的卡死，遇到这种问题有经验的PHPer会用strace -p命令查看当前PHP进程到底阻塞在哪个系统调用上面来定位问题，但这种方式有几个问题:

• 定位问题不清晰
  比如死锁这种问题strace的时候只能看到类似futex(0x7f4c8d567128, FUTEX_WAIT, 2, NULL)这种信息，非常的不直观，很多人根本不知道哪些PHP代码会触发futex系统调用，还有前文提到session_start那个问题，很多人根本不知道这里会触发flock，也就说很难根据一个系统调用定位到具体问题。
• 不知道-p哪一个进程
  我们线上环境通常会启动几十个甚至上百个PHP进程，在有些请求卡死，有些请求正常的情况下，你到底该strace -p哪个进程呢？貌似只能碰碰运气了。
• 发现不了死循环的问题
  由于strace命令的原理是追踪所有的系统调用，如果是前文提到的第一种情况，也就是死循环的卡死，strace根本无法获得任何有用的信息。此时我们只能用gdb工具来获取当前死循环在哪里具体，具体做法如下：首先：gdb attach后面接个进程id。
  然后：
  p (char *)executor_globals.current_execute_data.func.op_array.filename.val打印当前执行的PHP文件。
  p (char *)executor_globals.current_execute_data.func.op_array.function_name.val打印当前执行的函数名。
  p executor_globals.current_execute_data.opline.lineno打印当前执行的行数。
  进一步也可以获取调用堆栈这里就不展开了。
  但这明显太底层了，很多细节要注意，不精通PHP内核的人很难这样找问题（ps:通过.gdbinit能稍微减少点难度，但是也有很多其他问题）。

使用 Swoole Tracker 发现卡死问题

针对上述问题，Swoole官方出了一个解决方案 Swoole Tracker 的堆栈工具，同时支持 FPM 和Swoole。使用方法很简单：

• 首先点击上面的链接注册个账户。
• 然后装上swoole_tracker扩展。
• 最后登陆后台，在调试器=>进程列表中点击堆栈按钮就能获得当前卡在哪了，如图：

结尾

除了上面的卡死问题，还有一种情况是调用变慢，比如原来一个系统调用5ms，但是由于网络等等原因，这个调用100ms才返回，业务的表现是变慢了而不是卡死在那里，这种情况通过tracker的抓堆栈工具是无法定位问题的，因为卡住时间很短，很难抓到调用堆栈，此时需要Swoole工具链中的另外一个工具阻塞IO检测工具我们会在后面给大家介绍。

swoole、分布式之所以门槛高，主要体现在三方面：

涉及到的知识面广 ，Linux基础需要扎实，需要学会各种网络通信协议，如：TCP/UDP/UnixSocket等，同步异步阻塞非阻塞等，导致学习时经常混淆;

实践场景要求较高 ，一般小的项目不会用到这些技能，需要用到多进程、socket、千万级PV高并发等；即使知道些分布式相关的技术概念，也很难去落地，无法实践的技术很快就会被抛之脑后；

异常情况巨多 ，相比单机系统，分布式在每个环节上都要考虑繁杂的异常情况。比如单机系统中不存在的网络异常问题，那么在分布式系统中是家常便饭，任何一个有影响力的分布式框架都会花费大量的代码解决这些异常问题。

在“疫情”期间已经淘汰了一批末端的业务coder，现在是自己努力成为资深程序员的好时机，才能在面对高薪职位邀请时，做到胸有成竹。为了大家能够顺利进阶PHP中高级程序员、架构师，我为大家准备了一份中高级的教程福利！

作为web开发的佼佼者PHP并不逊色其他语言，加上swoole后更加是如虎添翼！进军通信 、物联网行业开发百度地图、百度订单中心等！年后更是霸占程序员招聘语言第二名，寒冬裁员期过后正是各大企业扩大招人的时期，现在市场初级程序员泛滥，进阶中高级程序员绝对是各大企业急需的人才，这套教程适合那些1-6年的PHP开发者进阶中高级提升自己，在春招中找到高薪职位！

领取方式：点赞关注小编后私信【资料】获取资料领取方式！

部分资料展示：

领取方式：点赞关注小编后私信【资料】获取资料领取方式！