确定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的调用以记录特定的syscall或syscall组。例如，要仅记录与文件访问相关的syscall，请使用：

strace -e文件-f -o日志....

如果strace对你来说太重了，试着监控：

使用"vmstat 1>//

1. “记录
2. 内存使用率-可能在此期间使用vmstat/iotop将进程换入(或换出)
3. IO使用率-可能某个其他进程正在颠覆vmstat-可能您的T1卡驱动程序遇到问题-

Answer 2

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

Answer 3

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