3

大多数用户空间进程在单元运行大约 3-4 天后进入 D 状态，该单元在 ARM 处理器上运行。从顶部 o/p 我们可以看到处于 D 状态的进程正在等待系统调用“page_fault”和“squashfs_readpage”。最终这会导致看门狗复位。进入 D-sate 的过程需要非常长的时间才能恢复。

以下是系统最终出现故障时的顶级 o/p：

top - 12:00:11 up 3 days,  2:40,  3 users,  load average: 2.77, 1.90, 1.72
Tasks: 250 total,   3 running, 238 sleeping,   0 stopped,   9 zombie
Cpu(s): 10.0% us, 75.5% sy,  0.0% ni,  0.0% id, 10.3% wa,  0.0% hi,  4.2% si
Mem:    191324k total,   188896k used,     2428k free,     2548k buffers
Swap:        0k total,        0k used,        0k free,    87920k cached



 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

 1003 root      20   0  225m  31m 4044 S 15.2 16.7   0:21.91 user_process_1             
 3745 root      20   0 80776 9476 3196 **D**  9.0  5.0   1:31.79 user_process_2                
  129 root      15  -5     0    0    0 S  7.4  0.0   0:27.65 **mtdblockd**          
 4624 root      20   0  3640  256  160 **D**  6.5  0.1   0:00.20 GetCounters_cus    
    3 root      15  -5     0    0    0 S  3.2  0.0  43:38.73 ksoftirqd/0        
31363 root      20   0  2356 1176  792 R  2.6  0.6  40:09.58 top                
  347 root      30  10     0    0    0 S  1.9  0.0  28:56.04 **jffs2_gcd_mtd3**     
 1169 root      20   0  225m  31m 4044 S  1.9 16.7  39:31.36 user_process_1             
  604 root      20   0     0    0    0 S  1.6  0.0  27:22.76 user_process_3           
 1069 root     -23   0  225m  31m 4044 S  1.3 16.7  20:45.39 user_process_1             
 4545 root      20   0  3640  564  468 S  1.0  0.3   0:00.08 GetCounters_cus    
   64 root      15  -5     0    0    0 **D**  0.3  0.0   0:00.83 **kswapd0**            
  969 root      20   0 20780 1856 1376 S  0.3  1.0  14:18.89 user_process_4             
  973 root      20   0  225m  31m 4044 S  0.3 16.7   3:35.74 user_process_1             
 1070 root     -23   0  225m  31m 4044 S  0.3 16.7  16:41.04 user_process_1             
 1151 root     -81   0  225m  31m 4044 S  0.3 16.7  23:13.05 user_process_1             
 1152 root     -99   0  225m  31m 4044 S  0.3 16.7   8:48.47 user_process_1

一个更有趣的观察是，当系统陷入这个问题时，我们可以始终看到“mtdblockd”进程在顶部 o/p 中运行。我们在这个单元上禁用了交换。单元中没有明显的内存泄漏。

知道可能的原因是什么，这些过程卡在 D 状态吗？

4

1 回答 1

3

D 状态意味着进程在 TASK_UNINTERRUPTIBLE 睡眠中卡在内核中，这不太可能是 Squashfs 错误处理代码中的错误，因为如果一个进程退出 Squashfs 持有互斥锁，系统将在其他进程进入时迅速停止Squashfs 并一直在等待互斥锁。您还会看到较低的平均负载/系统时间，因为大多数进程都处于休眠状态。此外，没有证据表明 Squashfs 遇到了任何 I/O 错误。

平均负载 (2.77) 和系统时间 (75.5%) 非常高，再加上很多进程都在 Squashfs_readpage 中（正在完成但速度很慢），表明系统正在颠簸。内存太少，系统花费所有时间不断（重新）从磁盘请求分页页面。这将说明很多进程都在 Squashfs_readpage 中，系统时间非常高，因为系统大部分时间都在 Squashfs 中用于解压的 CPU 密集型任务。其他进程卡在 Squashfs 中，等待解压器互斥锁（因为解压器状态是共享的，所以一次只能解压一个进程）。

于 2013-06-20T02:13:58.117 回答