记录一次排查PHP脚本执行卡住的问题

最近，我们注意到服务器中的一台机器运行异常，负载较高且与其他机器相比存在明显差异。经过初步排查，我们怀疑问题可能与PHP脚本执行有关。通过一系列步骤，我们最终成功解决了这个问题。在此，我将记录这次排查PHP脚本执行卡顿问题的过程，供需要的朋友参考。

一、发现问题

通过监控，我们发现在某一服务中的一台机器负载异常，相较于其他同机房的机器明显偏高。进一步的观察发现，这种现象在机房的每台机器上都有发生。经过梳理，我们发现存在问题的机器在执行PHP脚本时明显比正常机器耗时更长，因此我们初步猜测是PHP脚本执行出现了问题。

二、解决问题

为了验证我们的猜测，我们登录到机器上执行命令检查正在运行的PHP进程。我们发现存在一个CPU占用较高的PHP进程，进一步检查发现这是一个由crontab启动的PHP脚本执行时间过长。

之前我们遇到过类似的问题，当时怀疑是网络抖动导致的MySQL连接卡顿。于是我们将所有卡住的进程终止，从监控结果来看，机器负载确实有所降低。过了一段时间后，问题再次出现。这次我们决定深入调查问题根源。

我们首先尝试手动执行问题脚本以复现问题。我们发现手动执行脚本时也会出现卡顿现象，这表明问题并非简单如我们所想象的那样。接下来，我们使用strace命令查看卡住的进程当前正在执行的操作。strace命令并没有输出任何信息。

为了找出问题的线索，我们使用stat命令查看进程是否打开了哪些端口。我们发现该进程确实与MySQL和Redis建立了连接，并且连接状态分别为“ESTABLISHED”和“CLOSE_WAIT”。这让我们再次怀疑是与数据库的连接出现了问题。

为了验证我们的猜测，我们使用tcpdump抓包工具查看进程与数据库之间的交互情况。抓包文件并没有任何输出，这似乎表明进程与MySQL之间已经没有交互了。那为什么连接状态没有关闭呢？这个问题让我们陷入了困惑。

为了找到问题的根源，我们决定从头开始追踪脚本的执行情况。我们在PHP脚本的开始部分添加输出进程ID并暂停10秒的代码，然后启动tcpdump抓包工具进行抓包。执行PHP脚本后，我们在另一个窗口中执行strace命令以追踪进程的活动。

终于，这次strace和tcpdump都有了实质性的输出内容！我们终于可以深入了解问题的根源并采取相应的解决措施了。接下来我们将继续分析抓包文件以及strace的输出结果，以找出导致PHP脚本执行卡顿的具体原因并解决这一问题。从系统监控与调试的维度深入剖析一个问题

在一个平凡的工作日，我们的程序出现了一个看似神秘的停滞现象。借助工具，我们从不同的角度对这个问题进行，最终找到了问题的根源并解决它。这是一个充满挑战和收获的旅程，让我们来回顾一下。

我们通过 `poll` 系统调用监控文件描述符的活动状态。在 `recvfrom` 之后再次 `poll` 时，看似一切如常，但可能隐藏着玄机。`poll` 返回的结果表明，文件描述符仍然可读，但数据中是否隐藏着某种我们未察觉的问题呢？

进一步的抓包分析提供了更多线索。程序执行了两条 SQL 查询后，似乎停止了发送查询请求的包。从程序的 SQL 语句日志中，我们确认只执行了两条查询语句。这引发了一个疑问：为什么程序在此之后没有进一步的行动？

面对这样的困惑，我们决定深入代码进行调试。在关键的循环部分添加了输出语句，以便追踪程序的执行过程。当程序在查询 type 为 2 的时卡住时，我们注意到 `getSites()` 方法中可能存在问题。

`getSites()` 方法的主要任务是从数据库获取，并确保返回的不重复。代码中存在一个逻辑错误。当结果中的不重复数量少于预设值时，代码会进入一个死循环。具体到这个问题，当 type 为 2 的只有 6 个时，预设值为 8，因此产生了死循环。

这个问题从开始到解决花费了一天的时间。虽然问题最终被定位为一个低级的代码 BUG，但整个排查过程给我们带来了很多收获。最初的想法可能过于肤浅，但借助工具如 tcpdump 和 strace，我们能够深入理解问题的本质。这也提醒我们，需要更加熟练地运用这些工具，深入分析它们的结果。

回顾整个问题解决的流程，我们可以发现几个关键点：首先是对问题的细致观察和分析；其次是对工具的运用和结果的解读；最后是深入代码进行调试和问题解决。在这个过程中，我们不仅对技术有了更深入的理解，也锻炼了我们的分析和解决问题的能力。

这次经历对我们是一次宝贵的学习机会。面对问题，我们需要保持冷静，从多个角度进行分析，利用工具帮助我们找到问题的根源。希望这篇文章的内容能对大家的学习或工作有所帮助，如果有任何疑问，我们非常愿意交流。通过这次经历，我们更加深刻地认识到，技术的世界虽然复杂，但只要我们用心去，总能找到解决问题的方法。