5

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

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

哪些 linux 实用程序可能最适合捕获和分析这类事情，并且尽可能不引人注目，因为这是一个高负载系统？看起来，它需要是过程而不是面向系统的。也许对 /proc/pid/XX 的持续监控？Top 在这里似乎不太有用。

4

3 回答 3

8

如果您能够发现这个“无响应的时刻”，那么您可以使用 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 > /some/log”的内存使用情况 - 可能在此期间进程正在被换入（或换出）

  2. vmstat/iotop 的 IO 使用 - 可能是其他一些进程正在破坏磁盘

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

于 2008-10-21T21:34:53.373 回答
2

您可以对有问题的程序进行 strace 并查看它正在执行的系统调用。

于 2008-10-21T20:25:37.613 回答
0

谢谢 - strace 听起来很有用。在正确的时间抓住这个过程将是乐趣的一部分。我想出了一个定期将时间戳写入共享内存的方案，然后用另一个进程进行监控。然后，发送 SIGSTOP 至少可以让我使用 gdb 检查应用程序堆栈。我不知道暂停进程上的 strace 是否会告诉我很多信息，但我也许可以打开 strace 看看它会说什么。或者打开 strace 并使用 SIGCONT 访问该进程。

于 2008-10-21T22:04:50.503 回答