生產環境CPU狂飆900%，到底該如何處理？
首先，說明一下問題：CPU飆升200% 以上是生產環境非常容易發生的場景。
場景:1：MySQL進程飆升900%
大家在使用MySQL過程，想必都有遇到過CPU突然過高，或者達到200%以上的情況。
數據庫執行查詢或數據修改操作時，系統需要消耗大量的CPU資源維護從存儲系統、內存數據中的一致性。
并發量大并且大量SQL性能低的情況下，比如字段是沒有建立索引，則會導致快速CPU飆升，如果還開啟了慢日志記錄，會導致性能更加惡化。生產上有MYSQL 飆升900% 的惡劣情況。
場景2：Java進程飆升900%
一般來說Java 進程不做大量 CPU 運算，正常情況下，CPU 應該在 100~200% 之間，但是，一旦高并發場景，要么走到了死循環，要么就是在做大量的 GC, 容易出現這種 CPU 飆升的情況，CPU飆升900%，是完全有可能的。
其他場景：其他的類似進程飆升900%的場景
比如Redis、Nginx等等。
大家介紹場景的時候，就說自己主要涉及了兩個場景， Java進程飆升900%、MySQL進程飆升900%兩種場景，其實，這兩個場景就足夠講半天了， 其他的，使用規避技巧規避一下就行。
場景一：MySQL進程CPU飆升到900%，怎么處理？
定位過程
- 使用top 命令觀察，確定是mysqld導致還是其他原因。
- 如果是mysqld導致的，show processlist，查看session情況，確定是不是有消耗資源的sql在運行。
- 找出消耗高的 sql，看看執行計劃是否準確， index 是否缺失，或者實在是數據量太大造成。
處理過程
- kill 掉這些線程(同時觀察 cpu 使用率是否下降)， 一般來說，肯定要 kill 掉這些線程(同時觀察 cpu 使用率是否下降)，等進行相應的調整(比如說加索引、改 sql、改內存參數)之后，再重新跑這些 SQL。
- 進行相應的調整(比如說加索引、改 sql、改內存參數)index 是否缺失，如果是，則 建立索引。也有可能是每個 sql 消耗資源并不多，但是突然之間，有大量的 session 連進來導致 cpu 飆升，這種情況就需要跟應用一起來分析為何連接數會激增，再做出相應的調整，比如說限制連接數等;
- 優化的過程，往往不是一步完成的，而是一步一步，執行一項優化措辭，再觀察，再優化。
場景1的真實案例：MySQL數據庫優化的真實案例
以下案例，來自互聯網。大家參考一下，準備一個自己的案例。
本問題親身經歷過。
之前開發同事編寫的SQL語句，就導致過線上CPU過高，MySQL的CPU使用率達到900%+，通過優化最后降低到70%~80%。下面說說個人在這個過程中的排查思路。
首先，我們要對問題定位而不是盲目的開啟什么 慢日志，在并發量大并且大量SQL性能低的情況下，開啟慢日志無意是將MySQL推向崩潰的邊緣。
當時遇到這個情況，分析了當前的數據量、索引情況、緩存使用情況。目測數據量不大，也就幾百萬條而已。接下來就去定位索引、緩存問題。
1、經過詢問，發現很多查詢都是走MySQL，沒有用到緩存。
2、既然沒有用到緩存，則是大量請求全部查詢MySQL導致。通過下面的命令查看:
show processlist;發現類似很多相同的SQL語句，一直處于query狀態中。
select id form user where user_code = 'xxxxx';初步分析可能是 user_code 字段沒有索引導致。接著查詢user表的索引情況：
show index form user;發現這個字段是沒有建立索引。增加索引之后，該條SQL查詢能夠正常執行。
3、沒隔一會，又發生大量的請求超時問題。接著進行分析，發現是開啟了 慢日志查詢。大量的SQL查詢語句超過慢日志設置的閥值，于是將慢日志關閉之后，速度瞬間提升。CPU的使用率基本保持在300%左右。但還不是理想狀態。
4、緊接著將部分實時查詢數據的SQL語句，都通過緩存(redis)讀寫實現。觀察一段時間后，基本維持在了70%~80%。
總結：其實本次事故的解決很簡單，就是添加索引與緩存結合使用。
- 不推薦在這種CPU使用過高的情況下進行慢日志的開啟。因為大量的請求，如果真是慢日志問題會發生日志磁盤寫入，性能賊低。
- 直接通過MySQL show processlist命令查看，基本能清晰的定位出部分查詢問題嚴重的SQL語句，在針對該SQL語句進行分析。一般可能就是索引、鎖、查詢大量字段、大表等問題導致。
- 再則一定要使用緩存系統，降低對MySQL的查詢頻次。
- 對于內存調優，也是一種解決方案。
場景2展開：Java進程CPU飆升到900%，怎么處理？
定位過程：
CPU飆升問題定位的一般步驟是：
- 首先通過top指令查看當前占用CPU較高的進程PID；
- 查看當前進程消耗資源的線程PID：top -Hp PID
- 通過print命令將線程PID轉為16進制，根據該16進制值去打印的堆棧日志內查詢，查看該線程所駐留的方法位置。
- 通過jstack命令，查看棧信息，定位到線程對應的具體代碼。
- 分析代碼解決問題。
處理過程：
1、如果是空循環，或者空自旋。
處理方式：可以使用Thread.sleep或者加鎖，讓線程適當的阻塞。
2、在循環的代碼邏輯中，創建大量的新對象導致頻繁GC。比如，從mysql查出了大量的數據，比如100W以上等等。
處理方式：可以減少對象的創建數量，或者，可以考慮使用 對象池。
3、其他的一些造成CPU飆升的場景，比如 selector空輪訓導致CPU飆升 。
處理方式：參考Netty源碼，無效的事件查詢到了一定的次數，進行 selector 重建。
Java的CPU 飆升700%優化的真實案例
最近負責的一個項目上線，運行一段時間后發現對應的進程竟然占用了700%的CPU，導致公司的物理服務器都不堪重負，頻繁宕機。
那么，針對這類java進程CPU飆升的問題，我們一般要怎么去定位解決呢？
采用top命令定位進程
登錄服務器，執行top命令，查看CPU占用情況，找到進程的pid
top
圖片
很容易發現，PID為29706的java進程的CPU飆升到700%多，且一直降不下來，很顯然出現了問題。
使用top -Hp命令定位線程
使用 top -Hp命令（為Java進程的id號）查看該Java進程內所有線程的資源占用情況（按shft+p按照cpu占用進行排序，按shift+m按照內存占用進行排序）
此處按照cpu排序：
top -Hp 23602
圖片
很容易發現，多個線程的CPU占用達到了90%多。我們挑選線程號為30309的線程繼續分析。
使用jstack命令定位代碼
1.線程號轉換5為16進制
printf “%x\n” 命令（tid指線程的id號）將以上10進制的線程號轉換為16進制：
printf "%x\n" 30309
圖片
轉換后的結果分別為7665，由于導出的線程快照中線程的nid是16進制的，而16進制以0x開頭，所以對應的16進制的線程號nid為0x7665
2.采用jstack命令導出線程快照
通過使用dk自帶命令jstack獲取該java進程的線程快照并輸入到文件中：
jstack -l 進程ID > ./jstack_result.txt命令（為Java進程的id號）來獲取線程快照結果并輸入到指定文件。
jstack -l 29706 > ./jstack_result.txt3.根據線程號定位具體代碼
在jstack_result.txt 文件中根據線程好nid搜索對應的線程描述。
cat jstack_result.txt |grep -A 100 7665
圖片
根據搜索結果，判斷應該是ImageConverter.run()方法中的代碼出現問題。
當然，這里也可以直接采用。
jstack <pid> |grep -A 200 <nid>來定位具體代碼：
$jstack 44529 |grep -A 200 ae24
"System Clock" #28 daemon prio=5 os_prio=0 tid=0x00007efc19e8e800 nid=0xae24 waiting on condition [0x00007efbe0d91000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:340)
at java.util.concurrentC.TimeUnit.sleep(TimeUnit.java:386)
at com.*.order.Controller.OrderController.detail(OrderController.java:37) //業務代碼阻塞點分析代碼解決問題
下面是ImageConverter.run()方法中的部分核心代碼。
邏輯說明：
//存儲minicap的socket連接返回的數據 (改用消息隊列存儲讀到的流數據) ，設置阻塞隊列長度，防止出現內存溢出
//全局變量
private BlockingQueue<byte[]> dataQueue = new LinkedBlockingQueue<byte[]>(100000);
//消費線程
@Override
public void run() {
//long start = System.currentTimeMillis();
while (isRunning) {
//分析這里從LinkedBlockingQueue
if (dataQueue.isEmpty()) {
continue;
}
byte[] buffer = device.getMinicap().dataQueue.poll();
int len = buffer.length;
}在while循環中，不斷讀取堵塞隊列dataQueue中的數據，如果數據為空，則執行continue進行下一次循環。
如果不為空，則通過poll()方法讀取數據，做相關邏輯處理。
初看這段代碼好像每什么問題，但是如果dataQueue對象長期為空的話，這里就會一直空循環，導致CPU飆升。
那么如果解決呢？
分析LinkedBlockingQueue阻塞隊列的API發現：
//取出隊列中的頭部元素，如果隊列為空則調用此方法的線程被阻塞等待，直到有元素能被取出，如果等待過程被中斷則拋出InterruptedException
E take() throws InterruptedException;
//取出隊列中的頭部元素，如果隊列為空返回null
E poll();這兩種取值的API，顯然take方法更適合這里的場景。
代碼修改為：
while (isRunning) {
/* if (device.getMinicap().dataQueue.isEmpty()) {
continue;
}*/
byte[] buffer = new byte[0];
try {
buffer = device.getMinicap().dataQueue.take();
} catch (InterruptedException e) {
e.printStackTrace();
}
……
}重啟項目后，測試發現項目運行穩定，對應項目進程的CPU消耗占比不到10%。
圖片
