解決問題的思路：
1.top命令查看該機器的負載狀況
2.cd /proc/pid 查看對應高佔用程序的位置
3.進入對應程序中查看日誌，根據CPU和內存這兩個因素分析
4.ps -ajxf 查看進程及其之下的線程，通過下面指令的stat查看是否存在D殭屍進程
指令：ps -A -ostat,ppid,pid,cmd |grep -e '^[Zz]'
-A 參數列出所有進程
-o 自定義輸出字段 stat（狀態）、ppid（進程父id）、pid（進程id）、cmd（命令）
因爲狀態爲z或者Z的進程爲殭屍進程，所以我們使用grep抓取stat狀態爲zZ進程
1.什麼是負載過高
1.1load Average
1：load Average
1.1：什麼是Load？什麼是Load Average?
Load 就是對計算機幹活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）
簡單的說是進程隊列的長度。Load Average 就是一段時間（1分鐘、5分鐘、15分鐘）內平均Load。【參考文章：unix Load Average Part1：How It Works】
1.2：如何判斷系統是否已經Over Load？
對一般的系統來說，根據cpu數量去判斷。如果平均負載始終在1.2一下，而你有2顆cup的機器。那麼基本不會出現cpu不夠用的情況。也就是Load平均要小於Cpu的數量
1.3：Load與容量規劃（Capacity Planning）
一般是會根據15分鐘那個load 平均值爲首先。
1.4：Load誤解：
1：系統load高一定是性能有問題。
真相：Load高也許是因爲在進行cpu密集型的計算
2：系統Load高一定是CPU能力問題或數量不夠。
真相：Load高只是代表需要運行的隊列累計過多了。但隊列中的任務實際可能是耗Cpu的，也可能是耗i/0及其他因素的。
3：系統長期Load高，首先增加CPU
真相：Load只是表象，不是實質。增加CPU個別情況下會臨時看到Load下降，但治標不治本。
2：在Load average 高的情況下如何鑑別系統瓶頸。
是CPU不足，還是io不夠快造成或是內存不足？
2.1：查看系統負載vmstat
Vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 100152 2436 97200 289740 0 1 34 45 99 33 0 0 99 0
procs
r 列表示運行和等待cpu時間片的進程數，如果長期大於1，說明cpu不足，需要增加cpu。
b 列表示在等待資源的進程數，比如正在等待I/O、或者內存交換等。
cpu 表示cpu的使用狀態
us 列顯示了用戶方式下所花費 CPU 時間的百分比。us的值比較高時，說明用戶進程消耗的cpu時間多，但是如果長期大於50%，需要考慮優化用戶的程序。
sy 列顯示了內核進程所花費的cpu時間的百分比。這裏us + sy的參考值爲80%，如果us+sy 大於 80%說明可能存在CPU不足。
wa 列顯示了IO等待所佔用的CPU時間的百分比。這裏wa的參考值爲30%，如果wa超過30%，說明IO等待嚴重，這可能是磁盤大量隨機訪問造成的，也可能磁盤或者磁盤訪問控制器的帶寬瓶頸造成的(主要是塊操作)。
id 列顯示了cpu處在空閒狀態的時間百分比
system 顯示採集間隔內發生的中斷數
in 列表示在某一時間間隔中觀測到的每秒設備中斷數。
cs列表示每秒產生的上下文切換次數，如當 cs 比磁盤 I/O 和網絡信息包速率高得多，都應進行進一步調查。
memory
swpd 切換到內存交換區的內存數量(k表示)。如果swpd的值不爲0，或者比較大，比如超過了100m，只要si、so的值長期爲0，系統性能還是正常
free 當前的空閒頁面列表中內存數量(k表示)
buff 作爲buffer cache的內存數量，一般對塊設備的讀寫才需要緩衝。
cache: 作爲page cache的內存數量，一般作爲文件系統的cache，如果cache較大，說明用到cache的文件較多，如果此時IO中bi比較小，說明文件系統效率比較好。
swap
si 由內存進入內存交換區數量。
so由內存交換區進入內存數量。
IO
bi 從塊設備讀入數據的總量（讀磁盤）（每秒kb）。
bo 塊設備寫入數據的總量（寫磁盤）（每秒kb）
這裏我們設置的bi+bo參考值爲1000，如果超過1000，而且wa值較大應該考慮均衡磁盤負載，可以結合iostat輸出來分析。
2.2：查看磁盤負載iostat
每隔2秒統計一次磁盤IO信息，直到按Ctrl+C終止程序，-d 選項表示統計磁盤信息， -k 表示以每秒KB的形式顯示，-t 要求打印出時間信息，2 表示每隔 2 秒輸出一次。第一次輸出的磁盤IO負載狀況提供了關於自從系統啓動以來的統計信息。隨後的每一次輸出則是每個間隔之間的平均IO負載狀況。
# iostat -x 1 10
Linux 2.6.18-92.el5xen 02/03/2009
avg-cpu: %user %nice %system %iowait %steal %idle
1.10 0.00 4.82 39.54 0.07 54.46
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.16
rrqm/s: 每秒進行 merge 的讀操作數目。即 delta(rmerge)/s
wrqm/s: 每秒進行 merge 的寫操作數目。即 delta(wmerge)/s
r/s: 每秒完成的讀 I/O 設備次數。即 delta(rio)/s
w/s: 每秒完成的寫 I/O 設備次數。即 delta(wio)/s
rsec/s: 每秒讀扇區數。即 delta(rsect)/s
wsec/s: 每秒寫扇區數。即 delta(wsect)/s
rkB/s: 每秒讀K字節數。是 rsect/s 的一半，因爲每扇區大小爲512字節。(需要計算)
wkB/s: 每秒寫K字節數。是 wsect/s 的一半。(需要計算)
avgrq-sz: 平均每次設備I/O操作的數據大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O隊列長度。即 delta(aveq)/s/1000 (因爲aveq的單位爲毫秒)。
await: 平均每次設備I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次設備I/O操作的服務時間 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的時間用於 I/O 操作，或者說一秒中有多少時間 I/O 隊列是非空的。即 delta(use)/s/1000 (因爲use的單位爲毫秒)
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤
可能存在瓶頸。
idle小於70% IO壓力就較大了,一般讀取速度有較多的wait.
同時可以結合vmstat 查看查看b參數(等待資源的進程數)和wa參數(IO等待所佔用的CPU時間的百分比,高過30%時IO壓力高)
另外還可以參考
一般:
svctm < await (因爲同時等待的請求的等待時間被重複計算了)，
svctm的大小一般和磁盤性能有關:CPU/內存的負荷也會對其有影響，請求過多也會間接導致 svctm 的增加。
await: await的大小一般取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。
如果 svctm 比較接近 await，說明I/O 幾乎沒有等待時間；
如果 await 遠大於 svctm，說明 I/O隊列太長，應用得到的響應時間變慢，
如果響應時間超過了用戶可以容許的範圍，這時可以考慮更換更快的磁盤，調整內核 elevator算法，優化應用，或者升級 CPU。
隊列長度(avgqu-sz)也可作爲衡量系統 I/O 負荷的指標，但由於 avgqu-sz 是按照單位時間的平均值，所以不能反映瞬間的 I/O 洪水。
別人一個不錯的例子.(I/O 系統 vs. 超市排隊)
舉一個例子，我們在超市排隊 checkout 時，怎麼決定該去哪個交款臺呢? 首當是看排的隊人數，5個人總比20人要快吧?除了數人頭，我們也常常看看前面人購買的東西多少，如果前面有個採購了一星期食品的大媽，那麼可以考慮換個隊排了。還有就是收銀員的速度了，如果碰上了連錢都點不清楚的新手，那就有的等了。另外，時機也很重要，可能 5分鐘前還人滿爲患的收款臺，現在已是人去樓空，這時候交款可是很爽啊，當然，前提是那過去的 5 分鐘裏所做的事情比排隊要有意義(不過我還沒發現什麼事情比排隊還無聊的)。
I/O 系統也和超市排隊有很多類似之處:
r/s+w/s 類似於交款人的總數
平均隊列長度(avgqu-sz)類似於單位時間裏平均排隊人的個數
平均服務時間(svctm)類似於收銀員的收款速度
平均等待時間(await)類似於平均每人的等待時間
平均I/O數據(avgrq-sz)類似於平均每人所買的東西多少
I/O 操作率 (%util)類似於收款臺前有人排隊的時間比例。
我們可以根據這些數據分析出 I/O 請求的模式，以及 I/O 的速度和響應時間。
下面是別人寫的這個參數輸出的分析
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
上面的 iostat 輸出表明秒有 28.57 次設備 I/O 操作: 總IO(io)/s = r/s(讀) +w/s(寫) = 1.02+27.55 = 28.57 (次/秒) 其中寫操作佔了主體 (w:r = 27:1)。
平均每次設備 I/O 操作只需要 5ms 就可以完成，但每個 I/O 請求卻需要等上 78ms，爲什麼? 因爲發出的 I/O 請求太多 (每秒鐘約 29 個)，假設這些請求是同時發出的，那麼平均等待時間可以這樣計算:
平均等待時間 = 單個 I/O 服務時間 * ( 1 + 2 + ... + 請求總數-1) / 請求總數
應用到上面的例子: 平均等待時間 = 5ms * (1+2+...+28)/29 = 70ms，和 iostat 給出的78ms 的平均等待時間很接近。這反過來表明 I/O 是同時發起的。
每秒發出的 I/O 請求很多 (約 29 個)，平均隊列卻不長 (只有 2 個 左右)，這表明這 29 個請求的到來並不均勻，大部分時間 I/O 是空閒的。
一秒中有 14.29% 的時間 I/O 隊列中是有請求的，也就是說，85.71% 的時間裏 I/O 系統無事可做，所有 29 個 I/O 請求都在142毫秒之內處理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s=78.21 * delta(io)/s = 78.21*28.57 =2232.8，表明每秒內的I/O請求總共需要等待2232.8ms。所以平均隊列長度應爲 2232.8ms/1000ms = 2.23，而iostat 給出的平均隊列長度 (avgqu-sz) 卻爲 22.35，爲什麼?! 因爲 iostat 中有 bug，avgqu-sz值應爲 2.23，而不是 22.35。
什麼是cpu load 值
top命令中顯示的load average即爲最近1分鐘、5分鐘和15分鐘的系統平均負載。
系統平均負載被定義爲在特定時間間隔內運行隊列中(在CPU上運行或者等待運行多少進程)的平均進程數。如果一個進程滿足以下條件則其就會位於運行隊列中：
它沒有在等待I/O操作的結果
它沒有主動進入等待狀態(也就是沒有調用’wait’)
沒有被停止(例如：等待終止)
在Linux中，進程分爲三種狀態，一種是阻塞的進程blocked process(等待I/O設備的數據或者系統調)，一種是可運行的進程runnable process，另外就是正在運行的進程running process。
進程可運行狀態時，它處在一個運行隊列run queue中，與其他可運行進程爭奪CPU時間。 系統的load是指正在運行和準備好運行的進程的總數。比如現在系統有2個正在運行的進程，3個可運行進程，那麼系統的load就是5。load average就是一定時間內的load數量。
什麼因素構成了cpu load的大小
衡量CPU 系統負載的指標是load,load 就是對計算機系統能夠承擔的多少負載的度量,簡單的說是進程隊列的長度。請求大於當前的處理能力，會出現等待，引起load升高。
對於本文剛剛開頭顯示的 load average 0.21 0.10 0.03
很多人會這樣理解負載均值：三個數分別代表不同時間段的系統平均負載(一分鐘、五 分鐘、以及十五分鐘)，它們的數字當然是越小越好。數字越高，說明服務器的負載越大，這也可能是服務器出現某種問題的信號。而事實不完全如此，是什麼因素構成了負載均值的大小，以及如何區分它們目前的狀況是 “好”還是“糟糕”?什麼時候應該注意哪些不正常的數值?
回答這些問題之前，首先需要了解下這些數值背後的些知識。我們先用最簡單的例子說明， 一臺只配備一塊單核處理器的服務器。
行車過橋
一隻單核的處理器可以形象得比喻成一條單車道。設想下，你現在需要收取這條道路的過橋費 — 忙於處理那些將要過橋的車輛。你首先當然需要了解些信息，例如車輛的載重、以及 還有多少車輛正在等待過橋。如果前面沒有車輛在等待，那麼你可以告訴後面的司機通過。 如果車輛衆多，那麼需要告知他們可能需要稍等一會。
因此，需要些特定的代號表示目前的車流情況，例如：
0.00 表示目前橋面上沒有任何的車流。 實際上這種情況與 0.00 和 1.00 之間是相同的，總而言之很通暢，過往的車輛可以絲毫不用等待的通過。
1.00 表示剛好是在這座橋的承受範圍內。 這種情況不算糟糕，只是車流會有些堵，不過這種情況可能會造成交通越來越慢。
超過 1.00，那麼說明這座橋已經超出負荷，交通嚴重的擁堵。 那麼情況有多糟糕? 例如 2.00 的情況說明車流已經超出了橋所能承受的一倍，那麼將有多餘過橋一倍的車輛正在焦急的等待。3.00 的話情況就更不妙了，說明這座橋基本上已經快承受不了，還有超出橋負載兩倍多的車輛正在等待。
上面的情況和處理器的負載情況非常相似。一輛汽車的過橋時間就好比是處理器處理某線程 的實際時間。Unix 系統定義的進程運行時長爲所有處理器內核的處理時間加上線程在隊列中等待的時間。
和收過橋費的管理員一樣，你當然希望你的汽車(操作)不會被焦急的等待。所以，理想狀態 下，都希望負載平均值小於 1.00 。當然不排除部分峯值會超過 1.00，但長此以往保持這 個狀態，就說明會有問題，這時候你應該會很焦急。
“所以你說的理想負荷爲 1.00 ?”嗯，這種情況其實並不完全正確。負荷 1.00 說明系統已經沒有剩餘的資源了。在實際情況中 ，有經驗的系統管理員都會將這條線劃在 0.70。如果長期你的系統負載在 0.70 上下，那麼你需要在事情變得更糟糕之前，花些時間瞭解其原因。
多核處理器: 系統還是以處理器的核心數量計算負載均值
在多核處理中，你的系統均值不應該高於處理器核心的總數量。繼續針對上述的汽車過橋問題，如果是雙核CPU，那麼負載在2.0纔是負載滿額。如下是對於雙核處理器的輸出
uptime
17:57 up 22 days, 8:29, 3 users, load averages: 2.04 2.04 2.01
1
2
cpu load 過高原因以及排查
造成cpu load過高的原因.從編程語言層次上full gc次數的增大或死循環都有可能造成cpu load 增高
具體的排查一句話描述就是
2.如何查看負載過高
2.1top命令含義解釋
Linux系統可以通過top命令查看系統的CPU、內存、運行時間、交換分區、執行的線程等信息。通過top命令可以有效的發現系統的缺陷出在哪裏。是內存不夠、CPU處理能力不夠、IO讀寫過高。
0 綜述 使用SSHClient客戶端連接到遠程Linux系統。使用top命令查看系統的當前運行的情況。如圖對top命令執行的結果做了簡單的圖解，下面針對每一項做詳細的解釋。
1 top命令的第一行“top - 19:56:47 up 39 min, 3 users, load average: 0.00, 0.00, 0.00”顯示的內容依次爲“系統當前時間 、系統到目前爲止已運行的時間、當前登錄系統的用戶數量、系統負載(任務隊列的平均長度)三個值分別爲1分鐘、5分鐘、15分鐘前到現在的平均值【這三個一般會小於1，如果持續高於5，請仔細查看那個程序影響系統的運行】”
2 top命令的第二行“Tasks: 120 total, 2 running, 118 sleeping, 0 stopped, 0 zombie”顯示的內容依次“所有啓動的進程數”、“正在運行的進程數”、“掛起的進程數”、“停止的進程數”、“殭屍進程數”。
3 top命令的第三行“Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st”顯示的內容依次爲“用戶空間佔用CPU百分比”、“內核空間佔用CPU百分比”、“用戶空間內改變過優先級的進程佔用CPU百分比”、“空閒CPU百分比”、“等待輸入輸出CPU時間百分比”、“CPU服務於硬件中斷所耗費的時間總額”、“CPU服務軟中斷所耗費的時間總額”、“Steal Time”
4 top命令第四行“Mem: 508820k total, 480172k used, 28648k free, 41944k buffers”顯示內容依次爲“物理內存總量”、“已使用的物理內存”、“空閒物理內存”、“內核緩存內存量”。
5 top命令第5行“Swap: 392184k total, 0k used, 392184k free, 259152k cached”顯示內容依次爲“交換區總量”、“已使用交互區總量”、“空閒交換區總量”、“緩衝的交換區總量”。
6 top命令第5行“PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND ”顯示內容依次爲“進程ID”、“進程所有者”、“優先級”、“nice值，負值表示高優先級，正值表示低優先級”、“進程使用的虛擬內存總量”、“進程使用的、未被換出的物理內存大小”、“共享內存大小”、“進程狀態”、“上次更新到現在的CPU時間佔用百分比”、“進程使用的物理內存百分比”、“進程使用CPU總時間”、“命令名、命令行”。
1.2：查看指令：
w or uptime or procinfo or top
load average: 0.02, 0.27, 0.17
1 per/minute 5 per/minute 15 per/minute
3.發現負載過高的問題
4.解決負載過高的問題
2.MariaDB數據庫使用內存過大
MariaDB中的my.cnf配置文件的部分參數
[myisamchk]
key_buffer_size = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M
解決高負載過程記錄
1.MariaDB配置文件my.cnf參數優化
參數 原始值 修正後的值
max_connections 1000 300
table_open_cache 2048 64
max_allowed_packet 16M 1M
sort_buffer_size 8M 2M
innodb_buffer_pool_size 20G 2G
key_buffer_size 512M 20M
sort_buffer_size 512M 20M
配置文件：my.cnf
參考：https://www.centos.bz/2018/02/mariadb-mysql%E9%85%8D%E7%BD%AE%E6%96%87%E4%BB%B6my-cnf%E8%A7%A3%E8%AF%BB/
結果：mysql使用內存從35%降低到3.5%,影響到init進程的cpu佔用率，init進程的cpu佔用率從99%下降到15%左右
————————————————
版權聲明：本文爲CSDN博主「gu_study」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/gu_study/article/details/81942939