linux cpu高負載，top中沒有高占用cpu的進程。

load average還包含了不可中斷睡眠的進程，用iostat看看是不是在執(zhí)行磁盤IO。

ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpu
我搜到了這樣一個命令，然后在結果中看到了看了占用cpu的進程，是系統(tǒng)的占用，
root 30849 1 30858 03:16:37 99.7 [kacpi_notify]
root 30849 1 30859 03:16:35 99.7 [kacpi_notify]
root 30849 1 30860 03:16:36 99.7 [kacpi_notify]
root 30849 1 30861 03:16:37 99.7 [kacpi_notify]
root 30849 1 30863 03:16:37 99.7 [kacpi_notify]
root 30849 1 30864 03:16:38 99.7 [kacpi_notify]
root 30849 1 30865 03:16:36 99.7 [kacpi_notify]
root 30849 1 30866 03:16:38 99.7 [kacpi_notify]
在iotop中是可以看到這個進程的，但是io中沒有cpu占用，top中看不到 [kacpi_notify] acpi進程的通知進程 acpi是電源的接口，應該是機器太老的原因 ，用了十幾年的機器了。

主要是user用戶態(tài)占用，可以用perf top看一下熱點函數(shù)，根據(jù)熱點函數(shù)可以進一步推斷可能屬于哪個進程或程序。
perf工具當前主流的發(fā)行版都會有，但如果版本較老可能就沒有了。題主最好貼一下系統(tǒng)的版本信息。
類似下面這種：

hidtak@hidtak:~$ uname -a
Linux hidtak 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Intel的VTune是另外一種方法（試用版即可），老版本也可以用。

2018.5.31更新:
題主的內(nèi)核版本太老了，perf至少3.0內(nèi)核以上才支持。

這種問題分析起來比較麻煩，因為可能是底層的代碼BUG或機制缺陷；低版本內(nèi)核缺乏一些分析工具和手段，就更麻煩了。

我覺得只能采用比較笨的排除法了，因為題主提到過重啟后也會復現(xiàn)。（是立即復現(xiàn)？還是做了什么操作后？還是有了業(yè)務請求后？）。
那么系統(tǒng)啟動過程中會拉起一系列的服務和應用。一個個關閉排除就好了。

另外從原理上講2.6內(nèi)核版本統(tǒng)計CPU(核)占用率就是讀取/proc/stat文件，統(tǒng)計進程的占用率是讀取/proc/<pid>/stat文件。

那么我能想到的可能有幾種情況：

1）TOP的BUG，沒顯示全？或者排序方式不對？默認是按照CPU排序?。?br>這個容易確認，只需要看/proc下所有pid是否都在TOP中顯示了。注意TOP是分頁的；可以用top批處理選項，輸出到一個文件中。

2）內(nèi)核或底層代碼BUG。
可以通過Google相關案例看看，說不定可以找到類似BUG案例。

3）內(nèi)核被黑客攻擊了，并且注入了惡意代碼，導致/proc/內(nèi)沒有對應PID的節(jié)點生成，TOP讀取不到進程信息。
黑客一般不會單單占用一下CPU，通常會向外發(fā)送信息，否則對他也沒啥實際意義，所以可以通過監(jiān)控一下網(wǎng)絡活動看看是否有些痕跡，例如可以通過抓包看看是否有異常的網(wǎng)絡地址，異常的數(shù)據(jù)收發(fā)行為。
當然也有可能就是一個單純消耗CPU的病毒。
無論是病毒或木馬，重啟之后也存在，說明它在磁盤上有執(zhí)行文件，并且設置了自動啟動，在啟動配置里面肯定有體現(xiàn)，可以通過排除法也可以找到它。

以上供參考。