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

もう 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 でスタックします (圧縮解除プログラムの状態が共有されているため、一度に 1 つのプロセスしか圧縮解除できません)。

于 2013-06-20T02:13:58.117 に答える