1.前言

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

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

2.什么是平均負(fù)載？

使用命令

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

查看當(dāng)前系統(tǒng)的平均負(fù)載，前三個數(shù)分別是 1分鐘、5分鐘、15分鐘的平均進(jìn)程數(shù)。第四個的分子是正在運行的進(jìn)程數(shù)，分母是進(jìn)程總數(shù)；最后一個最近運行的進(jìn)程ID號。

或者使用

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

命令查看平均負(fù)載

• 08:24:29 //當(dāng)前時間

• up 19:34 //運行時間

• 0 users ?//當(dāng)前的用戶數(shù)量

• load average: 6.00, 6.00, 6.00 //分別是 1分鐘、5分鐘、15分鐘的平均進(jìn)程數(shù)

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

dumpsys?cpuinfo?

所以什么是平均負(fù)載？

簡單來說，平均負(fù)載是指單位時間內(nèi)，系統(tǒng)處于可運行狀態(tài)和不可中斷狀態(tài)的平均進(jìn)程數(shù)，也就是平均活躍進(jìn)程數(shù)，它和 CPU 使用率并沒有直接關(guān)系。

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

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

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

3.平均負(fù)載與 CPU 使用率？

現(xiàn)實工作中，我們經(jīng)常容易把平均負(fù)載和 CPU 使用率混淆，所以在這里，我也做一個區(qū)分。

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

我們還是要回到平均負(fù)載的含義上來，平均負(fù)載是指單位時間內(nèi)，處于可運行狀態(tài)和不可中斷狀態(tài)的進(jìn)程數(shù)。

所以，它不僅包括了正在使用 CPU 的進(jìn)程，還包括等待 CPU 和等待 I/O 的進(jìn)程。而 CPU 使用率，是單位時間內(nèi) CPU 繁忙情況的統(tǒng)計，跟平均負(fù)載并不一定完全對應(yīng)。

比如：

CPU 密集型進(jìn)程，使用大量 CPU 會導(dǎo)致平均負(fù)載升高，此時這兩者是一致的；I/O 密集型進(jìn)程，等待 I/O 也會導(dǎo)致平均負(fù)載升高，但 CPU 使用率不一定很高；大量等待 CPU 的進(jìn)程調(diào)度也會導(dǎo)致平均負(fù)載升高，此時的 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使用率不是很高

但是查看平均負(fù)載的時候，就很高

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

我們是4核CPU，如果平均負(fù)載低于4.0就是比較正常的，現(xiàn)在已經(jīng)遠(yuǎn)遠(yuǎn)高于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/

導(dǎo)入剛才的文件

w放大，s縮小

a左移，d右移

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

6.使用命令查看系統(tǒng)的D進(jìn)程

首先要了解下什么是D進(jìn)程

Linux進(jìn)程狀態(tài)

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

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

使用如下命令查看D進(jìn)程的backtrace

echo?w?>?proc/sysrq-trigger

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

然后查看內(nèi)核日志，可以看到如下關(guān)鍵信息

[?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個進(jìn)程屬于D進(jìn)程狀態(tài)，這幾個進(jìn)程一直在等待事件，導(dǎo)致CPU負(fù)載過高，但是實際上又沒有使用CPU，所以CPU使用率并不高。

使用命令查看我們系統(tǒng)的D進(jìn)程

為了驗證上面的說話，我們需要把系統(tǒng)中的D進(jìn)程干掉再繼續(xù)查看CPU負(fù)載。

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

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

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

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

7.1top 命令

top 可以查看系統(tǒng)CPU的狀態(tài)，以百分比的形式顯示出來。

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）：用戶態(tài)使用的cpu時間比。該值較高時，說明用戶進(jìn)程消耗的 CPU 時間比較多，比如，如果該值長期超過 50%，則需要對程序算法或代碼等進(jìn)行優(yōu)化。

• sy（system cpu time）：系統(tǒng)態(tài)使用的cpu時間比。

• ni（user nice cpu time）：用做nice加權(quán)的進(jìn)程分配的用戶態(tài)cpu時間比

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

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

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

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

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

7.2vmstat 1 命令

vmstat用來檢測系統(tǒng)的狀態(tài)，包括CPU和內(nèi)存，非常方便系統(tǒng)調(diào)試使用。

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

7.3pidstat 命令

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

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

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

常用參數(shù)：

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

7.4 查看系統(tǒng)的僵尸進(jìn)程

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

參考：

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

---

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

推薦閱讀：

專輯|Linux文章匯總

專輯|程序人生

專輯|C語言

我的知識小密圈

關(guān)注公眾號，后臺回復(fù)「1024」獲取學(xué)習(xí)資料網(wǎng)盤鏈接。

歡迎點贊，關(guān)注，轉(zhuǎn)發(fā)，在看，您的每一次鼓勵，我都將銘記于心~

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。