1.前言

最近在項目上遇到負載均衡過高的問題，分析好幾天，還因此移植了一個CPU檢測工具，后面在小二哥的指導找到了問題原因，小二哥有些讀者應該會比較熟悉，之前發的微信滑動卡頓就是他分析的，他是一個非常厲害的android系統工程師。

我這個問題比較棘手的是平均負載過高的時候，CPU占用和IOwait都是正常的，所以我第一時間還去查了僵尸進程，把僵尸進程都干掉后，發現CPU平均負載還是很高，最后在小二哥的提示下研究了下D進程，最后解決問題。

2.什么是平均負載？

使用命令

cat?/proc/loadavg? 6.00?6.00?6.00?1/721?5555

查看當前系統的平均負載，前三個數分別是 1分鐘、5分鐘、15分鐘的平均進程數。第四個的分子是正在運行的進程數，分母是進程總數；最后一個最近運行的進程ID號。

或者使用

uptime 08:24:29?up?19:34,??0?users,??load?average:?6.00,?6.00,?6.00

命令查看平均負載

• 08:24:29 //當前時間

• up 19:34 //運行時間

• 0 users ?//當前的用戶數量

• load average: 6.00, 6.00, 6.00 //分別是 1分鐘、5分鐘、15分鐘的平均進程數

還可以使用下面這個命令查看

dumpsys?cpuinfo?

所以什么是平均負載？

簡單來說，平均負載是指單位時間內，系統處于可運行狀態和不可中斷狀態的平均進程數，也就是平均活躍進程數，它和 CPU 使用率并沒有直接關系。

這里我先解釋下，可運行狀態和不可中斷狀態這倆詞兒。所謂可運行狀態的進程，是指正在使用 CPU 或者正在等待 CPU 的進程，也就是我們常用 ps 命令看到的，處于 R 狀態（Running 或 Runnable）的進程。

不可中斷狀態的進程則是正處于內核態關鍵流程中的進程，并且這些流程是不可打斷的，比如最常見的是等待硬件設備的 I/O 響應，也就是我們在 ps 命令中看到的 D 狀態（Uninterruptible Sleep，也稱為 Disk Sleep）的進程。

把CPU當作一座橋梁，當load 等于1的時候，橋梁上正好有足夠的汽車在行駛，當load等于0.5的時候，橋梁上還非常寬松，當load 等于1.7時候，說明已經有超負荷的汽車需要通過橋梁了。

3.平均負載與 CPU 使用率？

現實工作中，我們經常容易把平均負載和 CPU 使用率混淆，所以在這里，我也做一個區分。

可能你會疑惑，既然平均負載代表的是活躍進程數，那平均負載高了，不就意味著 CPU 使用率高嗎？

我們還是要回到平均負載的含義上來，平均負載是指單位時間內，處于可運行狀態和不可中斷狀態的進程數。

所以，它不僅包括了正在使用 CPU 的進程，還包括等待 CPU 和等待 I/O 的進程。而 CPU 使用率，是單位時間內 CPU 繁忙情況的統計，跟平均負載并不一定完全對應。

比如：

CPU 密集型進程，使用大量 CPU 會導致平均負載升高，此時這兩者是一致的；I/O 密集型進程，等待 I/O 也會導致平均負載升高，但 CPU 使用率不一定很高；大量等待 CPU 的進程調度也會導致平均負載升高，此時的 CPU 使用率也會比較高。

4.使用top命令查看CPU使用情況

使用top命令查看cpu使用情況

Tasks:?250?total,???1?running,?242?sleeping,???0?stopped,???1?zombie Mem:???2007724k?total,???862320k?used,??1145404k?free,????18576k?buffers Swap:??1505788k?total,????????0k?used,??1505788k?free,???415260k?cached 400%cpu???2%user???0%nice???1%sys?397%idle???0%iow???0%irq???0%sirq???0%hostPID?USER?????????PR??NI?VIRT??RES??SHR?S[%CPU]?%MEM?????TIME+?ARGS5645?root?????????20???0?6.4M?3.6M?2.9M?R??2.3???0.1???0:00.46?top515?system???????18??-2?1.1G?153M?134M?S??0.3???7.7???5:03.83?system_server318?shell????????20???0??12M?1.2M?1.0M?S??0.3???0.0???0:37.92?adbd?--root_seclabel=u:r:su:s05642?root??????????0?-20????0????0????0?S??0.0???0.0???0:00.00?[kworker/u9:1]5638?root?????????20???0????0????0????0?S??0.0???0.0???0:00.00?[kworker/u8:2]5614?root??????????0?-20????0????0????0?S??0.0???0.0???0:00.00?[kworker/u9:0]

可以看到cpu使用率不是很高

但是查看平均負載的時候，就很高

08:44:56?up?19:55,??0?users,??load?average:?6.00,?6.00,?6.00

我們是4核CPU，如果平均負載低于4.0就是比較正常的，現在已經遠遠高于4.0了。

5.使用trace查看cpuloading

先使用腳本抓取trace文件

get_trace.bat 文件

@echo?off adb?root adb?wait-for-device adb?rootrem?set?size adb?shell?"echo?16384?>?/sys/kernel/debug/tracing/buffer_size_kb" rem?set?or?use?debug?method adb?shell?"echo?nop?>?/sys/kernel/debug/tracing/current_tracer" rem?set?debug?event adb?shell?"echo?'sched_switch?sched_wakeup?sched_wakeup_new'?>?/sys/kernel/debug/tracing/set_event" rem?enable?debug rem?adb?shell?"echo?1?>?/sys/kernel/debug/tracing/tracing_enabled?>nul?2>&1" rem?stop?debug adb?shell?"echo?0?>?/sys/kernel/debug/tracing/tracing_on" rem?clear?debug?data? adb?shell?"echo?>?/sys/kernel/debug/tracing/trace"rem?wait?user?to?start echo?press?any?key?to?start?... pauserem?start?debug adb?shell?"echo?1?>?/sys/kernel/debug/tracing/tracing_on"rem?wait?user?to?stop echo?press?any?key?to?stop?... pauserem?stop?debug adb?shell?"echo?0?>?/sys/kernel/debug/tracing/tracing_on"echo?pull?debug?data?start?... adb?pull?/sys/kernel/debug/tracing/trace?sys_ftrace_data echo?pull?debug?data?endpause

獲取trace文件 sys_ftrace_data 。

通過谷歌瀏覽器打開地址

chrome://tracing/

導入剛才的文件

w放大，s縮小

a左移，d右移

通過分析CPU的使用情況，發現CPU工作不是非常繁忙，這和從TOP上看到的情況是一樣的。

6.使用命令查看系統的D進程

首先要了解下什么是D進程

Linux進程狀態

S (TASK_INTERRUPTIBLE)，可中斷的睡眠狀態

D (TASK_UNINTERRUPTIBLE)，不可中斷的睡眠狀態。

使用如下命令查看D進程的backtrace

echo?w?>?proc/sysrq-trigger

關于 sysrq-trigger的說明可以自行百度，可能會給你帶來驚喜。

然后查看內核日志，可以看到如下關鍵信息

[?6619.317533]?(0)[1621:sh]??task????????????????PC?stack???pid?father [?6619.317562]?(0)[1621:sh]GCPU????????????D?c0b6f590?????0????25??????2?0x00000000 [?6619.317576]?(0)[1621:sh]Backtrace:? [?6619.317585]?(0)[1621:sh][<c0b6f244>]?(__schedule)?from?[<c0b6faa0>]?(schedule+0x54/0xc4) [?6619.317609]?(0)[1621:sh]?r10:c1103948?r9:00000201?r8:c1103948?r7:c1103948 [?6619.317627]?(0)[1621:sh][<c0b6fa4c>]?(schedule)?from?[<c0b72e4c>]?(schedule_timeout+0x178/0x264) [?6619.317644]?(0)[1621:sh]?r4:7fffffff?r3:dc8ba692 [?6619.317655]?(0)[1621:sh][<c0b72cd4>]?(schedule_timeout)?from?[<c0b71bfc>]?(__down+0x78/0xc4) [?6619.317670]?(0)[1621:sh]?r10:c1103948?r9:00000201?r8:c1103948?r7:00000002 [?6619.317687]?(0)[1621:sh][<c0b71b84>]?(__down)?from?[<c018d2d0>]?(down+0x4c/0x60) [?6619.317705]?(0)[1621:sh]?r8:d038de88?r7:ffff1234?r6:c1103948?r5:d038ddcc [?6619.317721]?(0)[1621:sh][<c018d284>]?(down)?from?[<c070d630>]?(KREE_ServSemaphoreDown+0x14/0x1c) [?6619.317740]?(0)[1621:sh]?r4:c0cc5fd8 [?6619.317748]?(0)[1621:sh][<c070d61c>]?(KREE_ServSemaphoreDown)?from?[<c070bcf8>]?(tz_service_call+0x74/0xc4) [?6619.317767]?(0)[1621:sh][<c070bc84>]?(tz_service_call)?from?[<c070bf30>]?(KREE_TeeServiceCall+0xe8/0x290) [?6619.317781]?(0)[1621:sh]?r7:00000002?r6:00000001?r5:00000002?r4:00000000 [?6619.317799]?(0)[1621:sh][<c070be48>]?(KREE_TeeServiceCall)?from?[<c070c120>]?(kree_thread_function+0x48/0x64) [?6619.317814]?(0)[1621:sh]?r10:00000000?r9:00000000?r8:00000000?r7:c070c0d8 [?6619.317831]?(0)[1621:sh][<c070c0d8>]?(kree_thread_function)?from?[<c0148aec>]?(kthread+0x114/0x12c) [?6619.317849]?(0)[1621:sh]?r5:d0354d40?r4:00000000 [?6619.317862]?(0)[1621:sh][<c01489d8>]?(kthread)?from?[<c0108730>]?(ret_from_fork+0x14/0x24) [?6619.317908]?(0)[1621:sh]fuse_log????????D?c0b6f590?????0????78??????2?0x00000000 [?6619.317922]?(0)[1621:sh]Backtrace:? [?6619.317930]?(0)[1621:sh][<c0b6f244>]?(__schedule)?from?[<c0b6faa0>]?(schedule+0x54/0xc4) [?6619.317945]?(0)[1621:sh]?r10:00000000?r9:00000000?r8:00000000?r7:c0392b8c [?6619.317963]?(0)[1621:sh][<c0b6fa4c>]?(schedule)?from?[<c0148aa8>]?(kthread+0xd0/0x12c) [?6619.317977]?(0)[1621:sh]?r4:00000000?r3:cf9032c0 [?6619.317989]?(0)[1621:sh][<c01489d8>]?(kthread)?from?[<c0108730>]?(ret_from_fork+0x14/0x24) [?6619.318020]?(0)[1621:sh]hang_detect?????D?c0b6f590?????0???124??????2?0x00000000 [?6619.318034]?(0)[1621:sh]Backtrace:? [?6619.318043]?(0)[1621:sh][<c0b6f244>]?(__schedule)?from?[<c0b6faa0>]?(schedule+0x54/0xc4) [?6619.318137]?(0)[1621:sh]?r10:00000001?r9:c1102100?r8:df5ebb80?r7:c1103948 [?6619.318162]?(0)[1621:sh][<c0b6fa4c>]?(schedule)?from?[<c0b72e1c>]?(schedule_timeout+0x148/0x264) [?6619.318180]?(0)[1621:sh]?r4:001cfb65?r3:00000000 [?6619.318190]?(0)[1621:sh][<c0b72cd4>]?(schedule_timeout)?from?[<c01ad908>]?(msleep+0x34/0x40) [?6619.318209]?(0)[1621:sh]?r10:00000000?r9:c116e0a4?r8:cfb7dedc?r7:c116e158 [?6619.318228]?(0)[1621:sh][<c01ad8d4>]?(msleep)?from?[<c0733f5c>]?(hang_detect_thread+0x94/0x318) [?6619.318244]?(0)[1621:sh]?r5:c116e158?r4:c1483ba8 [?6619.318255]?(0)[1621:sh][<c0733ec8>]?(hang_detect_thread)?from?[<c0148aec>]?(kthread+0x114/0x12c) [?6619.318270]?(0)[1621:sh]?r10:00000000?r9:00000000?r8:00000000?r7:c0733ec8 [?6619.318286]?(0)[1621:sh][<c01489d8>]?(kthread)?from?[<c0108730>]?(ret_from_fork+0x14/0x24) [?6619.318320]?(0)[1621:sh]mt_gpufreq_inpu?D?c0b6f590?????0???164??????2?0x00000000 [?6619.318333]?(0)[1621:sh]Backtrace:? [?6619.318340]?(0)[1621:sh][<c0b6f244>]?(__schedule)?from?[<c0b6faa0>]?(schedule+0x54/0xc4) [?6619.318354]?(0)[1621:sh]?r10:00000000?r9:00000000?r8:00000000?r7:c0512ebc [?6619.318370]?(0)[1621:sh][<c0b6fa4c>]?(schedule)?from?[<c0148aa8>]?(kthread+0xd0/0x12c) [?6619.318384]?(0)[1621:sh]?r4:00000000?r3:cf825e40 [?6619.318395]?(0)[1621:sh][<c01489d8>]?(kthread)?from?[<c0108730>]?(ret_from_fork+0x14/0x24) [?6619.318412]?(0)[1621:sh]display_esd_che?D?c0b6f590?????0???169??????2?0x00000000 [?6619.318424]?(0)[1621:sh]Backtrace:? [?6619.318432]?(0)[1621:sh][<c0b6f244>]?(__schedule)?from?[<c0b6faa0>]?(schedule+0x54/0xc4) [?6619.318446]?(0)[1621:sh]?r10:00000000?r9:00000000?r8:00000000?r7:c0620888 [?6619.318463]?(0)[1621:sh][<c0b6fa4c>]?(schedule)?from?[<c0148aa8>]?(kthread+0xd0/0x12c) [?6619.318477]?(0)[1621:sh]?r4:00000000?r3:cfbfe580 [?6619.318487]?(0)[1621:sh][<c01489d8>]?(kthread)?from?[<c0108730>]?(ret_from_fork+0x14/0x24) [?6619.318510]?(0)[1621:sh]entropy_thread??D?c0b6f590?????0???182??????2?0x00000000 [?6619.318523]?(0)[1621:sh]Backtrace:? [?6619.318531]?(0)[1621:sh][<c0b6f244>]?(__schedule)?from?[<c0b6faa0>]?(schedule+0x54/0xc4) [?6619.318545]?(0)[1621:sh]?r10:c1103948?r9:00020107?r8:c1103948?r7:c1103948 [?6619.318562]?(0)[1621:sh][<c0b6fa4c>]?(schedule)?from?[<c0b72e4c>]?(schedule_timeout+0x178/0x264) [?6619.318577]?(0)[1621:sh]?r4:7fffffff?r3:dc8ba692 [?6619.318587]?(0)[1621:sh][<c0b72cd4>]?(schedule_timeout)?from?[<c0b71bfc>]?(__down+0x78/0xc4) [?6619.318602]?(0)[1621:sh]?r10:c1103948?r9:00020107?r8:c1103948?r7:00000002 [?6619.318619]?(0)[1621:sh][<c0b71b84>]?(__down)?from?[<c018d2d0>]?(down+0x4c/0x60) [?6619.318634]?(0)[1621:sh]?r8:ced01e68?r7:0000002d?r6:c1103948?r5:ced01dac [?6619.318651]?(0)[1621:sh][<c018d284>]?(down)?from?[<c070d630>]?(KREE_ServSemaphoreDown+0x14/0x1c) [?6619.318666]?(0)[1621:sh]?r4:c0cc5fd8 [?6619.318674]?(0)[1621:sh][<c070d61c>]?(KREE_ServSemaphoreDown)?from?[<c070bcf8>]?(tz_service_call+0x74/0xc4) [?6619.318689]?(0)[1621:sh][<c070bc84>]?(tz_service_call)?from?[<c070bf30>]?(KREE_TeeServiceCall+0xe8/0x290) [?6619.318703]?(0)[1621:sh]?r7:00000002?r6:00000001?r5:00000003?r4:00000000 [?6619.318720]?(0)[1621:sh][<c070be48>]?(KREE_TeeServiceCall)?from?[<c070e418>]?(entropy_thread+0xfc/0x228) [?6619.318734]?(0)[1621:sh]?r10:00000000?r9:00000000?r8:00000000?r7:c1103948 [?6619.318751]?(0)[1621:sh][<c070e31c>]?(entropy_thread)?from?[<c0148aec>]?(kthread+0x114/0x12c) [?6619.318765]?(0)[1621:sh]?r7:c070e31c?r6:00000000?r5:cf703080?r4:00000000 [?6619.318781]?(0)[1621:sh][<c01489d8>]?(kthread)?from?[<c0108730>]?(ret_from_fork+0x14/0x24) [?6619.318999]?(0)[1621:sh]Sched?Debug?Version:?v0.11,?4.4.146?#10 [?6619.319008]?(0)[1621:sh]ktime???????????????????????????????????:?6619310.281712 [?6619.319016]?(0)[1621:sh]sched_clk???????????????????????????????:?6619318.998704 [?6619.319024]?(0)[1621:sh]cpu_clk?????????????????????????????????:?6619318.998857 [?6619.319032]?(0)[1621:sh]jiffies?????????????????????????????????:?1895794 [?6619.319040]?(0)[1621:sh] [?6619.319045]?(0)[1621:sh]sysctl_sched [?6619.319052]?(0)[1621:sh]??.sysctl_sched_latency????????????????????:?10.000000 [?6619.319060]?(0)[1621:sh]??.sysctl_sched_min_granularity????????????:?2.250000 [?6619.319068]?(0)[1621:sh]??.sysctl_sched_wakeup_granularity?????????:?2.000000 [?6619.319076]?(0)[1621:sh]??.sysctl_sched_child_runs_first???????????:?0 [?6619.319084]?(0)[1621:sh]??.sysctl_sched_features???????????????????:?36667 [?6619.319091]?(0)[1621:sh]??.sysctl_sched_tunable_scaling????????????:?0?(none) [?6619.319099]?(0)[1621:sh]

從日志里面可以看到有6個進程屬于D進程狀態，這幾個進程一直在等待事件，導致CPU負載過高，但是實際上又沒有使用CPU，所以CPU使用率并不高。

使用命令查看我們系統的D進程

為了驗證上面的說話，我們需要把系統中的D進程干掉再繼續查看CPU負載。

display_esd_che 這個進程看起來是和ESD靜電相關，可能在屏幕死掉后才會被觸發，這個是內核線程，所以我修改了內核代碼，重新燒錄再查看CPU負載。

0:/?#?uptime 17:55:09?up??1:11,??0?users,??load?average:?3.09,?3.08,?3.12

可以明顯看到CPU負載已經變低了，我們是4核CPU，平均負載低于4.0就屬于正常。

7.排查問題需要用到的幾個命令解釋

7.1top 命令

top 可以查看系統CPU的狀態，以百分比的形式顯示出來。

Tasks:?251?total,???1?running,?243?sleeping,???0?stopped,???1?zombie Mem:???2007724k?total,???862108k?used,??1145616k?free,????18560k?buffers Swap:??1505788k?total,????????0k?used,??1505788k?free,???415260k?cached 400%cpu??16%user???0%nice???6%sys?377%idle???0%iow???0%irq???0%sirq???0%hostPID?USER?????????PR??NI?VIRT??RES??SHR?S[%CPU]?%MEM?????TIME+?ARGS5628?root?????????20???0?5.9M?3.1M?2.7M?R?19.3???0.1???0:00.07?top5614?root??????????0?-20????0????0????0?S??0.0???0.0???0:00.00?[kworker/u9:0]5609?root?????????20???0????0????0????0?S??0.0???0.0???0:00.00?[kworker/3:2]5607?root?????????20???0????0????0????0?S??0.0???0.0???0:00.00?[kworker/u8:2]5590?root??????????0?-20????0????0????0?S??0.0???0.0???0:00.00?[kworker/u9:4]5585?root?????????20???0????0????0????0?S??0.0???0.0???0:00.00?[kworker/u8:3]5577?root??????????0?-20????0????0????0?S??0.0???0.0???0:00.00?[kworker/u9:2]5571?root?????????20???0????0????0????0?S??0.0???0.0???0:00.00?[kworker/3:0]5537?root?????????20???0????0????0????0?S??0.0???0.0???0:00.05?[kworker/u8:1]5448?root?????????20???0????0????0????0?S??0.0???0.0???0:00.67?[kworker/3:1]

• us（user cpu time）：用戶態使用的cpu時間比。該值較高時，說明用戶進程消耗的 CPU 時間比較多，比如，如果該值長期超過 50%，則需要對程序算法或代碼等進行優化。

• sy（system cpu time）：系統態使用的cpu時間比。

• ni（user nice cpu time）：用做nice加權的進程分配的用戶態cpu時間比

• id（idle cpu time）：空閑的cpu時間比。如果該值持續為0，同時sy是us的兩倍，則通常說明系統則面臨著 CPU 資源的短缺。

• wa（wait）：等待使用CPU的時間。

• hi（hardware irq）：硬中斷消耗時間

• si（software irq）：軟中斷消耗時間

• st（steal time）：虛擬機偷取時間

7.2vmstat 1 命令

vmstat用來檢測系統的狀態，包括CPU和內存，非常方便系統調試使用。

procs?-----------memory----------?---swap--?-----io----?-system--?----cpu----r??b???swpd???free???buff??cache???si???so????bi????bo???in???cs?us?sy?id?wa1??0??????0?1146440?18564?415260????0????0?????2?????1????0???95??0??0?100?00??0??????0?1146476?18564?415260????0????0?????0?????0????0??384??0??0?100?00??0??????0?1146104?18564?415260????0????0?????0?????0????0??375??0??0?100?00??0??????0?1146724?18564?415260????0????0?????0?????0????0??387??0??0?100?00??0??????0?1146848?18564?415260????0????0?????0?????0????0??369??0??0?100?0

類別項目含義說明

Procs**（進程）**	r	等待執行的任務數	展示了正在執行和等待cpu資源的任務個數。當這個值超過了cpu個數，就會出現cpu瓶頸。
B	等待IO的進程數量
Memory(內存)	swpd	正在使用虛擬的內存大小，單位k
free	空閑內存大小
buff	已用的buff大小，對塊設備的讀寫進行緩沖
cache	已用的cache大小，文件系統的cache
inact	非活躍內存大小，即被標明可回收的內存，區別于free和active	具體含義見：概念補充（當使用-a選項時顯示）
active	活躍的內存大小	具體含義見：概念補充（當使用-a選項時顯示）
Swap	si	每秒從交換區寫入內存的大小（單位：kb/s）
so	每秒從內存寫到交換區的大小
IO	bi	每秒讀取的塊數（讀磁盤）	塊設備每秒接收的塊數量，單位是block，這里的塊設備是指系統上所有的磁盤和其他塊設備，現在的Linux版本塊的大小為1024bytes
bo	每秒寫入的塊數（寫磁盤）	塊設備每秒發送的塊數量，單位是block
system	in	每秒中斷數，包括時鐘中斷	這兩個值越大，會看到由內核消耗的cpu時間sy會越多 秒上下文切換次數，例如我們調用系統函數，就要進行上下文切換，線程的切換，也要進程上下文切換，這個值要越小越好，太大了，要考慮調低線程或者進程的數目
cs	每秒上下文切換數
CPU**（以百分比表示）**	us	用戶進程執行消耗cpu時間(user time)	us的值比較高時，說明用戶進程消耗的cpu時間多，但是如果長期超過50%的使用，那么我們就該考慮優化程序算法或其他措施了
sy	系統進程消耗cpu時間(system time)	sys的值過高時，說明系統內核消耗的cpu資源多，這個不是良性的表現，我們應該檢查原因。這里us + sy的參考值為80%，如果us+sy 大于 80%說明可能存在CPU不足
Id	空閑時間(包括IO等待時間)	一般來說 us+sy+id=100
wa	等待IO時間	wa過高時，說明io等待比較嚴重，這可能是由于磁盤大量隨機訪問造成的，也有可能是磁盤的帶寬出現瓶頸。

7.3pidstat 命令

這個命令在Android上是沒有的，我在github上找到了個半成品，編譯了出來安裝到我們的設備上

https://github.com/weiqifa0/pidstat/blob/main/README.md

pidstat主要用于監控全部或指定進程占用系統資源的情況，如CPU，內存、設備IO、任務切換、線程等。pidstat首次運行時顯示自系統啟動開始的各項統計信息，之后運行pidstat將顯示自上次運行該命令以后的統計信息。用戶可以通過指定統計的次數和時間來獲得所需的統計信息。

常用參數：

-C?comm??#只顯示那些包含字符串（可是正則表達式）comm的命令的名字-d???#顯示I/O統計信息（須內核2.6.20及以后）PID???????????#進程號kB_rd/s???#每秒此進程從磁盤讀取的千字節數kB_wr/s???#此進程已經或者將要寫入磁盤的每秒千字節數kB_ccwr/s???#由任務取消的寫入磁盤的千字節數Command???#命令的名字-h???#顯示所有的活動的任務-I???#在SMP環境，指出任務的CPU使用（等同于選項-u）應該被除于cpu的總數-l???#顯示進程的命令名和它的參數-p?{?pid?[,...]?|?SELF?|?ALL?}??#指定線程顯示其報告-r???#顯示分頁錯誤的內存利用率When?reporting?statistics?for?individual?tasks,?the?following?values?are?displayed:PID???????????#進程號minflt/s???#每秒次缺頁錯誤次數(minor?page?faults)，次缺頁錯誤次數意即虛擬內存地址映射成物理內存地址產生的page?fault次數majflt/s???#每秒主缺頁錯誤次數(major?page?faults)，當虛擬內存地址映射成物理內存地址時，相應的page在swap中，這樣的page?fault為major?page?fault，一般在內存使用緊張時產生VSZ???????????#該進程使用的虛擬內存(以kB為單位)RSS???????????#該進程使用的物理內存(以kB為單位)%MEM???#當前任務使用的有效內存的百分比Command???#任務的命令名?????????????When?reporting?global?statistics?for?tasks?and?all?their?children,?the?following?values?are?displayed:PID???????????#PID號minflt-nr???#在指定的時間間隔內收集的進程和其子進程的次缺頁錯誤次數majflt-nr???#在指定的時間間隔內收集的進程和其子進程的主缺頁錯誤次數Command???#命令名-s???#堆棧的使用-t???#顯示與所選任務相關的線程的統計數據-T { TASK | CHILD | ALL }?#指定必須監測的內容：TASK是默認的，單個任務的報告；CHILD：指定的進程和他們的子進程的全局報告，ALL：相當于TASK和CHILD-u???#報告CPU使用When?reporting?statistics?for?individual?tasks,?the?following?values?are?displayed:?PID%usr???#用戶層任務正在使用的CPU百分比（with?or?without?nice?priority?，NOT?include?time?spent?running?a?virtual?processor）%system???#系統層正在執行的任務的CPU使用百分比%guest???#運行虛擬機的CPU占用百分比%CPU???#所有的使用的CPU的時間百分比CPU???????????#處理器數量Command???#命令When?reporting?global?statistics?for?tasks?and?all?their?children,?the?following?values?are?displayed:PID???????????#PID號usr-ms???#在指定時間內收集的在用戶層執行的進程和它的子進程占用的CPU時間（毫秒）{with?or?without?nice?priority，NOT?include?time?spent?running?a?virtual?processor)system-ms???#在指定時間內收集的在系統層執行的進程和它的子進程占用的CPU時間（毫秒）guest-ms???#花在虛擬機上的時間Command???#命令-V???#版本號-w???#報告任務切換情況PID???????????#PID號cswch/s???#每秒自動上下文切換nvcswch/s???#每秒非自愿的上下文切換Command???#命令

7.4 查看系統的僵尸進程

ps?-A?-o?stat,ppid,pid,cmd?|?grep?-e?'^[Zz]'

參考：

https://blog.csdn.net/qq_23864697/article/details/110671859

---

好了，放下小二哥的公眾號，喜歡安卓技術的可以勾搭他，喜歡籃球的也可以。

推薦閱讀：

專輯|Linux文章匯總

專輯|程序人生

專輯|C語言

我的知識小密圈

關注公眾號，后臺回復「1024」獲取學習資料網盤鏈接。

歡迎點贊，關注，轉發，在看，您的每一次鼓勵，我都將銘記于心~

總結

以上是生活随笔為你收集整理的项目实战，平均负载过高，最后发现却是这个搞鬼的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。