一、CPU的構成：
1.【lscpu】
2.【vmstst】
buff 緩沖：降低和磁盤交互的頻率，比如垃圾桶，滿了倒垃圾
cache 緩存：更快的取數據，比如家里的葯箱，只有常用的葯
二、CPU利用率.【top】{他是一個時間百分比，一般的監控是cpu利用的總和，並不能分析是有效利用還是無效利用，要去服務器上看是不是us和sy高}
看下面圖：PID這一行的%CPU是邏輯和的利用率，雙核可以達到200%，4核的話可以到400%
圖中的load是平均時間內1分鍾5分鍾15分鍾內的任務數
在期間 敲 1
1.cpu(s):物理核 cps邏輯核
2. us：用戶空間
sy：系統空間
ni：進程優先級切換（優先級高的進程會搶占cpu，切換多ni就會高）
id：空閑，wa：等待IO讀寫（磁盤和網絡）
wa：IO等待（網絡和磁盤，wa過高說明磁盤網絡出現異常）
hi：硬中斷（硬件引起的，比如磁盤，網絡，鍵盤，hi超出10%說明cpu有很嚴重的問題）
si：軟中斷 （cpu陷入到內核空間執行讀寫數據），他是內核層面的，si很高的話，一定是在做數據讀寫，可能是死循環，可能在寫日志（日志級別低、內核層面的系統調用，此時需要打印內核層面的設備日志）
st：虛擬機，用的不多，不用管
us和sy是有效利用率【us高也可能是代碼問題，sync和yield會導致高】
其他都是無效利用率
dmesg | grep sda 硬盤
dmesg | more 內核
dmesg | grep eth 網卡日志
dmesg | head -20 輸出前 20 行設備日志
dmesg | tail -20 輸出后 20 行日志
dmesg | grep -i memory 查看內存日志
dmesg | grep -i usb 查看 usb 日志
dmesg -c 清空緩沖日志
watch "dmesg | tail -20" 實時監控設備日志
日志中出現關鍵字 oom kill ddos等就是有問題了，就要分析
比如這個，內存溢出，殺死了進程
這個例子就是寫日志，但是沒有空間寫了，導致si很高
3.【watch -d cat /proc/interrupts】查看硬中斷
左邊的數字是中斷號，最右邊的是硬件名稱，對應綁定的cup
4.【watch -d cat /proc/softirqs】查看軟中斷
【ethtool -1 eth0】網卡隊列
三、進程和線程
1.進程：分配資源
2.線程：任務調度
a.cpu線程【執行調度】
1.cpu的核數表示一次性可以調度的任務數
2.cpu時間片分配
a.2核調度2個任務
b.2核調度20個任務，其中18個任務排隊
c.任務越多時間片越少，切換越快，（切換一定伴隨cpu中斷）導致cpu消耗很高，當時間片用完cpu會切換到下一個任務【被動切換】，下圖in是中斷，cs是切換
b和c一起就是cpu的上下文切換，計數器【存儲任務位置】和寄存器【存儲任務數據】
【pidstat -w -p {PID}】查看上下文切換數據
cswch 主動切換 （內存不足，io有問題） nvcswch 被動切換（時間片用完了）
c.load
A.平均時間內，系統同步處理的任務數，對應1分鍾5分鍾15分鍾
B.從左到右，遞減【負載在增加】反之【負載正在降低】
C.如果雙核load現在是2 目前是滿載狀態，load大於核數，說明是過載狀態，是可以處理的，是在排隊處理 【vmstst 1 10】
(1) load=r+b
(2) r -->runnable 等待資源 running 等待獲取線程鎖
(3) b -->black 拿到了線程鎖， 處於不可中斷的狀態
D.舉個例子：【stress-ng -c 20 -t 100】 此時查看top
b.應用線程【被調度】：將數據編譯成cpu可以識別的內存指令，提交cpu，cpu去調度，cpu的核數越多，同步調度的任務數就越多
1.tomcat
2.nginx
3.mysql
c.特殊任務對cpu的消耗
1.tomcat長連接到期，線程釋放
2.nginx 驚群，線程批量啟動和休眠
d.系統調用
敲top，處於用戶空間，敲下之后需要內核空間申請數據，切換到內核空間，內核空間會給出一個api讓用戶調用，在切換到用戶空間調用api。->一次調用，兩次切換
【strace -o strace.log -tt -p {線程號、進程號}】系統調用日志
e.進程優先級
1.NI：優先級系數，范圍-20到+19 【在top下面敲 r 回車 進程號 回車 NI的系數 回車】
2.PR：值越高，優先級越低
3.優先級越高，進程獲取的cpu時間片越多，可以搶占cpu
打java堆棧腳本 bash show-busy-java-threads 上傳到服務器，執行可以看到消耗cpu最高的幾個線程打出來
總結幾個常見的問題：
1.us高：可能是算法問題，函數sync【刷磁盤】和yield【放棄cpu】可能會導致
2.sy高：a.日志頻繁讀寫，如日志權限不夠或者路徑不存在（cpu利用率會滿），日志級別問題。
b.內核故障，如內存問題和網絡問題（打印內存日志【dmesg | more】可以看出）
c.頻繁的系統調用 【strace -o strace.log -tt -p {線程號、進程號}】系統調用日志
3.利用率過低
a.壓力不夠
b.參數配置-連接池
（1）數據庫連接數
（2）中間件隊列
（3）tcp隊列
c.網絡阻塞
（1）tcp
（2）socket
（3）本地網管
（4）防火牆
4.內核使用不均衡
進程綁定cpu taskset -pc 0-3 pid 進程綁定邏輯核（進程重啟時效）
5.無效利用
ni過高：修改進程優先級
wa過高：磁盤分析，網卡分析（切片多不多，cpu輪詢數據包的總量）
6.hi 磁盤、網卡（網卡隊列，網卡中斷綁定）
7.si 內核中斷，參考sy
CPU常用命令
mpstat
mpstat -P {cpu l ALL}
mpstat -I SCPU 1 統計軟中斷
pidstat -w -p 查看進程上下文切換
sar -u 1 5 采集cpu使用率
sar -q 1 5 采集進程隊列和負載狀態
ps aux | sort -k3nr |head -n 10 按照按照消耗CPU前10排序的進程
perf top 定位cpu熱點
watch "dmesg | tail -20" 實時監控設備日志
taskset -pc 0-3 pid 進程綁定邏輯cpu
echo 1 > /sys/devices/system/cpu/cpu1/online 開啟邏輯cpu
strace -o strace.log -tt -p 【pid】打印內核日志
sync【刷磁盤】
yield【放棄cpu】
watch -d cat /proc/softirqs 實時查看軟中斷
watch -d cat /proc/interrupts 統計進程中斷的方式
sysstat
mpstat【cpu】
vmstat【cpu】
iostat【磁盤】
netstat【網絡】
pidstat【進程】