最近經常收到告警，CPU load大於閾值告警。查看系統的CPU是12核，告警閾值設置的是8。對於CPU load一直有個模糊的概念，具體是什么意思還真搞不明白，趁這個機會好好搞搞究竟。
1.查看CPU load
查看CPU load的方法很多，我經常用個最簡單的命令：uptime
[linux@b28-34-98 ~]$ uptime
16:09:32 up 530 days, 1 min, 1 user, load average: 2.71, 2.44, 1.99
命令結果的后三位就是load的值了，分別代表1分鍾、5分鍾、15分鍾的平均值。因為是平均值，15分鍾更能代表系統的整體負載情況，如果1分鍾的值很高，其他兩個值很低，只能說明系統有瞬間的高負載。如果15分鍾內，系統的平均負載都很大，表明問題持續存在，不是暫時現象。那么CPU load這個值多少算大呢，和CPU核數又有什么關系呢？
2.CPU load含義
CPU load是一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息。
2.1單核CPU
當CPU完全空閑的時候，平均負荷為0（即load average的值為0）；當CPU工作量飽和的時候，平均負荷為1；當有線程等待時，平均負荷為等待線程數+1，如果這個時候等待線程過多，等待時間就會長，需要考慮增加CPU 了。
來個經典比喻：
不妨把這個CPU想象成一座大橋，橋上只有一根車道，所有車輛都必須從這根車道上通過（很顯然，這座橋只能單向通行），大橋的通行能力（一次10輛車），就是CPU的最大工作量；橋梁上的車輛，就是一個個等待CPU處理的進程（process）。
1）系統負荷為0，意味着大橋上一輛車也沒有。
2）系統負荷為0.5，意味着大橋一半的路段有車。
3）系統負荷為1.0，意味着大橋的所有路段都有車，也就是說大橋已經"滿"了。但是必須注意的是，直到此時大橋還是能順暢通行的。
4）系統負荷為1.7，意味着車輛太多了，大橋已經被占滿了（100%），后面等着上橋的車輛為橋面車輛的70%。
以此類推，系統負荷2.0，意味着等待上橋的車輛與橋面的車輛一樣多； 系統負荷3.0，意味着等待上橋的車輛是橋面車輛的2倍。 總之，當系統負荷大於1，后面的車輛就必須等待了；系統負荷越大，過橋就必須等得越久。 CPU的系統負荷，基本上等同於上面的類比。為了服務器順暢運行，系統負荷最好不要超過1.0，這樣就沒有進程需要等待了，所有進程都能第一時間得到處理。 很顯然，1.0是一個關鍵值，超過這個值，系統就不在最佳狀態了，就需要動手干預了。
2.2多核CPU
當CPU核數是4時，系統的處理能力是單核CPU的4倍，這時候CPU工作量飽和時，平均負荷為4，即每個CPU正在處理一個負荷。
類比到這個小車過橋的比喻中，4核CPU相當於4車道大橋。
1）系統負荷為0，意味着大橋上一輛車也沒有。
2）系統負荷為1.0，意味着大橋只有一條車道占滿，其他車道空閑着，其實也不一定所有車輛擠一條車道上，可以平均分配到不同車道，每條車道負載0.25。
3）系統負荷為4，意味着大橋的4條路段都有車，也就是說大橋已經"滿"了。但是必須注意的是，直到此時大橋還是能順暢通行的。
4）系統負荷大於4，意味着車輛太多了，大橋已經被占滿了（100%），后面已經有等着上橋的車輛了。
3.CPU load多大合適
這個仁者見仁，有人覺得CPU負載小於等於"內核數乘以0.5-0.7"算是一種理想狀態。 比如4核CPU的服務器，理想負載是小於等於2，最好不要超過2.8，否則性能多少會受影響。個人感覺這個要具體情況具體分析，在監控中設置成CPU核數即可，當然如果長時間觀察到CPU load飽滿運行，就需要多加注意了。