linux - 如何识别，是什么让 Linux 系统停滞不前？

Question

我有一个嵌入式系统，当我进行用户输入/输出操作时，系统就停止了。它会在很长一段时间后执行操作。这个系统相当复杂，有很多进程在运行。我的问题是如何确定导致系统停止运行的原因 - 它在 5 分钟内什么也没做。 5分钟后，我看到了结果。我真的不知道是什么让系统停滞不前。有关如何调试此问题的任何输入。我已经在系统上运行了 top。但是，这不会导致任何问题。看这里，jup_render 只占用了 30% 的 CPU，这不足以让系统停止运行。所以，我不确定 top 在这里是否有用。

~#顶

top - 12:01:05 向上 21 分钟，1 位用户，平均负载:1.49、1.26、0.87任务:总共116个，运行2个， sleep 114个，停止0个，僵尸0个中央处理器:44.4%us、13.9%sy、0.0%ni、40.3%id、0.0%wa、0.0%hi、1.4%si、0.0%st内存:总计 822572k，已用 389640k，空闲 432932k，缓冲区 1980k交换:总共 0k，已使用 0k，免费 0k，缓存 227324k

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND          
850 root      20   0  309m  32m  16m S   30  4.0   3:10.88 jup_render                                                                            
  870 root      20   0  221m  13m  10m S   27  1.7   2:28.78 jup_render                                                                            
  688 root      20   0 1156m 4092 3688 S   11  0.5   1:25.49 rxserver                                                                               
    9 root      20   0     0    0    0 S    2  0.0   0:06.81 ksoftirqd/1                                                                            
   16 root      20   0     0    0    0 S    1  0.0   0:06.87 ksoftirqd/3                                                                            
 9294 root      20   0  1904  616  508 R    1  0.1   0:00.10 top                                                                                    
  812 root      20   0  865m  85m  46m S    1 10.7   1:21.17 lippo_main                                                                               
   13 root      20   0     0    0    0 S    1  0.0   0:06.59 ksoftirqd/2                                                                            
  800 root      20   0  223m 8316 6268 S    1  1.0   0:08.30 rat-cadaemon                                                                        
    3 root      20   0     0    0    0 S    1  0.0   0:05.94 ksoftirqd/0                                                                            
 1456 root      20   0 80060  10m 8208 S    1  1.2   0:04.82 jup_render                                                                            
 1330 root      20   0  202m  10m 8456 S    0  1.3   0:06.08 jup_render                                                                            
 8905 root      20   0  1868  556  424 S    0  0.1   0:02.91 dropbear                                                                               
 1561 root      20   0 80084  10m 8204 S    0  1.2   0:04.92 jup_render                                                                            
  753 root      20   0 61500 7376 6184 S    0  0.9   0:04.06 ale_app                                                                                
 1329 root      20   0 79908   9m 8208 S    0  1.2   0:04.77 jup_render                                                                            
  631 dbus      20   0  3248 1636  676 S    0  0.2   0:13.10 dbus-daemon                                                                            
 1654 root      20   0 80068  10m 8204 S    0  1.2   0:04.82 jup_render                                                                            
  760 root      20   0  116m  15m  12m S    0  1.9   0:10.19 jup_server                                                                            
    8 root      20   0     0    0    0 S    0  0.0   0:00.00 kworker/1:0                                                                            
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd                                                                               
    7 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/1                                                                            
  170 root       0 -20     0    0    0 S    0  0.0   0:00.00 kblockd                                                                                
    6 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0                                                                            
  167 root      20   0     0    0    0 S    0  0.0   0:00.00 sync_supers                                                                            
  281 root       0 -20     0    0    0 S    0  0.0   0:00.00 nfsiod   

Answer 1

对于一个有很多进程运行的嵌入式系统，可能有很多原因。您可能需要从各个角度进行调查。

检查竞争条件和死锁的代码。内核可能在某种情况下忙于循环。在某些情况下，您的应用程序正在等待 select 调用或 CPU 资源已用完(根据您共享的 top 命令的输出排除了这种 CPU 资源使用选择)或在读取时受阻。

如果您正在执行阻塞 I/O 操作，进程将进入等待队列，并且只有在请求完成后才移回执行路径(就绪队列)。也就是说，它被移出调度程序运行队列并置于特殊状态。仅当它们从 sleep 中醒来或等待的资源可用时，才应将其放回运行队列。

立即执行的步骤是尝试“strace”。它应拦截/记录进程调用的系统调用以及进程接收的信号。它将能够显示事件的顺序和调用的所有返回/恢复路径。这可以使您更接近问题所在。

还有许多其他方便的工具可以根据您的开发环境/设置进行尝试。主要工具如下:

'iotop' - 它通过监视内核输出的 I/O 使用信息，为您提供系统上进程或线程当前 I/O 使用情况的表格。

'LTTng' - 可以跟踪竞争条件和中断级联。它是 LTT 的继任者。它是 kprobes、tracepoint 和 perf 功能的组合。

'Ftrace' - 这是一个 Linux 内核内部跟踪器，您可以使用它来分析/调试与延迟和性能相关的问题。

如果您的系统基于 TI 处理器，CCS(跟踪分析器)提供了对系统事件执行非侵入式调试和分析的功能。因此，请注意，根据您的设置，您可能还需要使用相关工具。

遇到了更多的想法:ma​​gic SysRq key 是 linux 中的另一个选项。如果驱动程序卡住了，命令 SysRq p 可以将您带到导致问题的确切例程。

数据剖析可以准确判断内核将时间花在了哪里。有几个工具，如 Readprofile 和 Oprofile。 Oprofile 可以通过配置 CONFIG_PROFILING 和 CONFIG_OPROFILE 来启用。另一种选择是通过启用分析选项和使用 Readprofile 实用程序读取配置文件计数器来重建内核，方法是通过命令行使用 profile=2 启动。

mpstat 可以通过“iowait”参数给出“在系统有未完成的磁盘 I/O 请求期间 CPU 空闲的时间百分比”。