如何識別，什麼是在Linux系統停滯？

我有一個嵌入式系統，當我做用戶I/O操作時，系統只是停止。它在很長一段時間後纔開始行動。這個系統非常複雜，並且有很多進程正在運行。我的問題是，如何識別造成系統失速的原因 - 它在5分鐘內沒有任何字面意思。 5分鐘後，我看到了結果。我真的不知道什麼是拖延系統。有關如何調試此問題的任何輸入。我已經在系統上運行了頂層。但是，它不會導致任何問題。看到這裏，jup_render只佔CPU的30％，這不足以拖延系統。所以，我不確定top是否有用。如何識別，什麼是在Linux系統停滯？

〜＃頂部

頂部 - 12時01分05秒21向上分鐘，1個用戶，平均負載：1.49，1.26，0.87 任務：116總，2運行，114睡眠，0停止，0殭屍 Cpu：44.4％us，13.9％sy，0.0％ni，40.3％id，0.0％wa，0.0％hi，1.4％si，0.0％st Mem：總共822572k，使用389640k，432932k free，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

來源

2014-10-27 dexterous_stranger

你在做什麼類型的I/O操作會觸發它？ – 2014-10-27 15:45:19

讓我承認這個系統是一個機頂盒。我做了一個頻道zap。 – 2014-10-28 06:22:00

對於有很多進程運行的嵌入式系統，可能有多種原因。您可能需要從各個角度進行調查。

檢查競爭條件和死鎖的代碼。內核可能正忙於在特定條件下循環。可能會出現應用程序正在等待選定呼叫或CPU資源已用完（根據您所共享的頂級命令的輸出排除此CPU資源使用情況的選擇）或讀取時被阻止的情況。

如果您正在執行阻塞I/O操作，則進程將進入等待隊列，並且僅在請求完成後才移回執行路徑（就緒隊列）。也就是說，它從調度程序運行隊列中移出並放入特殊狀態。只有當它們從睡眠中喚醒或等待的資源可用時，它纔會被放回到運行隊列中。

立即執行'strace'。它應攔截/記錄由進程調用的系統調用以及進程接收的信號。它將能夠顯示事件的順序以及呼叫的所有返回/恢復路徑。這可以讓你幾乎接近問題領域。

還有其他很多方便的工具可以根據您的開發環境/設置進行嘗試。主要工具如下：

「iotop」 - 它由內核監控I/O的使用信息輸出系統爲您提供電流I/O利用率的表由進程或線程。

'LTTng' - 使跟蹤的競爭條件和中斷級聯成爲可能。它是LTT的繼承者。它是kprobes，tracepoint和perf功能的組合。

'Ftrace' - 這是一個Linux內核內部跟蹤程序，您可以使用它分析/調試延遲和性能相關問題。

如果您的系統基於TI處理器，CCS（跟蹤分析器）提供了對系統活動進行非侵入式調試和分析的功能。所以，請注意，根據您的設置，您可能還需要使用相關工具。

遇到幾個更多的想法： 魔法SysRq鍵是Linux中的另一種選擇。如果驅動程序卡住了，命令SysRq p可以將您帶到導致問題的確切程序。

數據分析可以確定內核花費的時間。有幾個工具，如Readprofile和Oprofile。 Oprofile可以通過配置CONFIG_PROFILING和CONFIG_OPROFILE來啓用。另一個選項是通過啓用配置文件選項並使用Readprofile實用程序通過命令行啓動profile=2來讀取配置文件計數器來重建內核。

mpstat可以通過'iowait'參數給出'CPU或CPU處於空閒狀態的時間百分比，在此期間系統有一個突出的磁盤I/O請求'。

來源

2014-10-28 03:29:38

你說你運行top應用。你有沒有發現哪個程序的CPU時間最長，以及它的百分比是多少？

如果您運行top您應該會看到另一個屏幕，您既沒有提供也沒有提及CPU負載百分比（或其他相關信息）。

enter image description here

我勸你，包括你可以發現，有趣/相關的或可疑的通過top。如果已經完成，您應該更明確地在您的問題中發現它，因爲現在不明白什麼是CPU最大負載。

來源

2014-10-27 11:43:31

我現在編輯了我的問題。我現在已經提供了更多信息。 – 2014-10-27 12:23:58

如何識別，什麼是在Linux系統停滯？

回答

相關問題