确定在Linux上停止进程的原因

Question

我正在尝试确定在Linux上停滞过程的原因。这是一个电信应用程序，在相当重的负载下运行。 8个T1跨度中的每一个都有一个单独的过程。每隔一段时间，其中一个进程就会变得非常无响应 - 在通常非常繁忙的进程日志中记录事件之前可能需要50秒。

可能有些系统资源不足。显而易见的事情 - CPU使用率 - 看起来没问题。

哪种Linux实用程序可能最适合捕获和分析此类事物，并尽可能不引人注意，因为这是一个高负载的系统？它似乎需要是流程而不是系统导向。也许正在持续监控/ proc / pid / XX？ Top在这里似乎没什么用处。

Answer 1

如果你能够发现这个“无反应的时刻”，那么在这段时间你可能会使用strace附加到相关进程并试图找出它“睡觉”的位置：

strace -f -o LOG -p <pid>

更轻巧，但不太可靠的方法：

1. 当进程挂起时，使用top / ps / gdp / strace / ltrace来查找进程的状态（例如，它是否在“select”中等待或在某些库调用中消耗100％cpu）

2. 了解相关调用的一般性质，定制strace的调用以记录特定的系统调用或系统调用。例如，要仅记录与文件访问相关的系统调用，请使用：

   strace -e file -f -o LOG ....
   

如果strace太重了，请尝试监控：

1. 使用“vmstat 1＆gt; / some / log”的内存使用情况 - 可能会在此期间交换（或退出）

2. 使用vmstat / iotop进行IO使用 - 也许其他一些进程正在颠覆磁盘

3. / proc / interrupts - 也许您的T1卡的驱动程序遇到了问题？

Answer 2

您可以对有问题的程序进行分析，看看系统正在调用它。

Answer 3

谢谢 - strace听起来很有用。在正确的时间捕捉过程将是乐趣的一部分。我想出了一个方案，定期将时间戳写入共享内存，然后用另一个进程监视。然后发送SIGSTOP会让我至少用gdb检查应用程序堆栈。我不知道暂停过程中的strace是否会告诉我很多，但我可能会打开strace并看看它会说些什么。或者打开strace并使用SIGCONT点击进程。