php bt tracker,PHP 教你使用 Swoole-Tracker 秒级定位 PHP 卡死问题

最新推荐文章于 2024-07-17 20:34:20 发布

长亮不灭

最新推荐文章于 2024-07-17 20:34:20 发布

阅读量314

点赞数

文章标签： php bt tracker

1 <?php2 while(1){3 //do something

4 if($condition){5 //满足条件后退出循环

6 break;7 }8 }

上述代码通过$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

wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

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

3.flock函数导致卡死

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

//do something

fwrite($fp, "the huge stringn");flock($fp, LOCK_UN); //释放锁定

}

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

注意还有很多其他类型的锁即使进程被kill也不会自动被释放。

这个8k是可以改的，和glibc中的fwrite很多细节也不一样.

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

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

<?php $cli = newSwooleClient(SWOOLE_SOCK_TCP);if ($cli->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行获得锁的位置，同时第一个协程也永远无法恢复继续执行。

while ($c--) {

go(function () use ($lock) {//创建协程

$lock->lock();//获得锁

Co::sleep(1);//让出cpu

$lock->unlock();//释放锁

});

}

wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

如何发现卡死

上述只是举了一些例子，真实业务中还有各种姿势的卡死，遇到这种问题有经验的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官方出了一个解决方案 Swoole Tracker 的堆栈工具，同时支持FPM和Swoole。

使用方法很简单：

首先点击上面的连接注册个账户。

然后装上swoole_tracker扩展。

最后登陆后台，在调试器=>进程列表中点击堆栈按钮就能获得当前卡在哪了，如图：

wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

结尾

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