我正在尝试确定 Linux 上进程停滞的原因。这是一个电信应用程序，在相当重的负载下运行。 8 个 T1 跨度中的每一个都有一个单独的过程。每隔一段时间，其中一个进程就会变得非常无响应 - 在通常非常繁忙的进程日志中记录事件之前最多可能 50 秒。
可能是某些系统资源不足。显而易见的事情 - CPU 使用率 - 看起来没问题。
哪些 linux 实用程序可能最适合捕获和分析这类事情，并且尽可能不引人注目，因为这是一个高负载系统？看起来，它需要是过程而不是面向系统的。也许对 /proc/pid/XX 的持续监控？顶部在这里似乎不太有用。
【问题讨论】：
标签： linux process resources stalled
如果您能够发现这个“无响应的时刻”，那么您可以使用 strace 来附加到该期间的相关进程，并尝试找出它“休眠”的位置：
strace -f -o LOG -p <pid>
更轻量级但不太可靠的方法：
当进程挂起时，使用 top/ps/gdp/strace/ltrace 找出进程的状态（例如它是否在“select”中等待或在某些库调用中消耗 100% cpu）
了解相关调用的一般性质，定制 strace 调用以记录特定的系统调用或系统调用组。例如，要仅记录与文件访问相关的系统调用，请使用：
strace -e file -f -o LOG ....
如果 strace 对你来说太重了，试试监控：
“vmstat 1 > /some/log”的内存使用情况 - 可能在此期间进程正在被换入（或换出）
vmstat/iotop 的 IO 使用情况 - 可能其他一些进程正在破坏磁盘
/proc/interrupts - 您的 T1 卡的驱动程序可能出现问题？
【讨论】：
您可以对有问题的程序进行 strace 并查看它正在执行的系统调用。
【讨论】：
谢谢 - strace 听起来很有用。在正确的时间抓住这个过程将是乐趣的一部分。我想出了一个方案，定期将时间戳写入共享内存，然后用另一个进程进行监控。然后，发送 SIGSTOP 至少可以让我使用 gdb 检查应用程序堆栈。我不知道暂停进程上的 strace 是否会告诉我很多信息，但我也许可以打开 strace 看看它会说什么。或者打开 strace 并使用 SIGCONT 访问进程。
【讨论】：