2. 程式人生 > >伺服器cpu負載過高問題排查

伺服器cpu負載過高問題排查

阿新 • • 發佈：2019-01-17

第一步 ：執行top命令，查出當前機器執行緒情況

top - 09:14:36 up 146 days, 20:24,  1 user,  load average: 0.31, 0.37, 0.45
Tasks: 338 total,   1 running, 337 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.4%us,  0.4%sy,  0.0%ni, 99.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16331456k total, 14017124k used,  2314332k free,   316724k buffers
Swap: 16506876
 
k total,    36200k used, 16470676k free,  5151404k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                              
 6107 root      20   0 9724m 1.3g  15m S  8.0  8.4 624:22.34 java                                                                                                  
26678
 
 root      20   0 9643m 498m  17m S  8.0  3.1  61:34.58 java                                                                                                  
10168 root      20   0 12.9g 4.7g  12m S  1.7 30.0 329:11.58 java                                                                                                  
11291
 
 root      20   0 9654m 1.2g  15m S  0.7  7.7  35:17.04 java                                                                                                  
28662 root      20   0 15168 1436  940 R  0.7  0.0   0:00.12 top                                                                                                   
   61 root      20   0     0    0    0 S  0.3  0.0   4:10.55 ksoftirqd/14                                                                                          
   68 root      20   0     0    0    0 S  0.3  0.0 119:58.11 events/1                                                                                              
 2987 root      20   0     0    0    0 S  0.3  0.0  31:22.27 flush-253:2                                                                                           
    1 root      20   0 19344 1204  980 S  0.0  0.0   0:03.71 init

第二步：通過jstack命令dump當前記憶體中執行緒資訊
jstack 26678

[root@172_16_1_177 logs]# jstack 26678
2017-08-30 10:34:29
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode):

"Attach Listener" daemon prio=10 tid=0x00007f96dc001000 nid=0x70d5 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"DubboServerHandler-172.16.1.177:28082-thread-50" daemon prio=10 tid=0x00007f967c001800 nid=0x70a1 waiting on condition [0x00007f9543040000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000ca928680> (a java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
    at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:925)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

"DubboServerHandler-172.16.1.177:28082-thread-49" daemon prio=10 tid=0x00007f95f820c000 nid=0x708e waiting on condition [0x00007f9543081000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000ca928680> (a java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
    at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:925)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

"DubboServerHandler-172.16.1.177:28082-thread-48" daemon prio=10 tid=0x00007f9674001800 nid=0x7085 waiting on condition [0x00007f95430c2000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000ca928680> (a java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
    at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:925)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

"DubboServerHandler-172.16.1.177:28082-thread-47" daemon prio=10 tid=0x00007f95f820a000 nid=0x7084 waiting on condition [0x00007f9543103000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000ca928680> (a java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
    at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:925)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

"DubboServerHandler-172.16.1.177:28082-thread-46" daemon prio=10 tid=0x00007f95f8207800 nid=0x7082 waiting on condition [0x00007f9543144000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000000ca928680> (a java.util.concurrent.SynchronousQueue$TransferStack)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
    at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:925)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

4.1、使用方案
cpu飆高，load高，響應很慢
方案：
* 一個請求過程中多次dump
* 對比多次dump檔案的runnable執行緒，如果執行的方法有比較大變化，說明比較正常。如果在執行同一個方法，就有一些問題了。
查詢佔用cpu最多的執行緒資訊
方案：
* 使用命令： top -H -p pid（pid為被測系統的程序號），找到導致cpu高的執行緒id。
上述Top命令找到的執行緒id，對應著dump thread資訊中執行緒的nid，只不過一個是十進位制，一個是十六進位制。
* 在thread dump中，根據top命令查詢的執行緒id，查詢對應的執行緒堆疊資訊。
cpu使用率不高但是響應很慢
方案：
* 進行dump，檢視是否有很多thread struck在了i/o、資料庫等地方，定位瓶頸原因。
請求無法響應
方案：
* 多次dump，對比是否所有的runnable執行緒都一直在執行相同的方法，如果是的，恭喜你，鎖住了！

相關推薦

伺服器cpu負載過高問題排查

第一步 ：執行top命令，查出當前機器執行緒情況 top - 09:14:36 up 146 days, 20:24, 1 user, load average: 0.31, 0.37, 0.45 Tasks: 338 total, 1 running

伺服器CPU負載過高，如何定位問題

CPU負載過高解決問題過程： 1，根據top命令，發現PID為12433的Java程序佔用CPU高達300%，出現故障。 2，找到該程序後，如何定位具體執行緒或程式碼呢，首先顯示執行緒列表,並按照CPU佔用高的執行緒排序： [[email protected] logs]# ps -mp  1243

linux 排查cpu負載過高異常

問：如何定位是哪個服務程序導致CPU過載，哪個執行緒導致CPU過載，哪段程式碼導致CPU過載？ 步驟一、找到最耗CPU的程序 工具：top 方法： 執行top -c ，顯示程序執行資訊列表 鍵入P (大寫p)，程序按照CPU使用率排序 圖示： 如上圖，最耗CPU的程序P

CPU負載過高異常排查實踐與總結

昨天下午突然收到運維郵件報警，顯示資料平臺伺服器cpu利用率達到了98.94%，而且最近一段時間一直持續在70%以上，看起來像是硬體資源到瓶頸需要擴容了，但仔細思考就會發現咱們的業務系統並不是一個高併發或者CPU密集型的應用，這個利用率有點太誇張，硬體瓶頸應該不會這麼快就到了，一定是哪裡的業務程式碼邏輯有問題

排查tomcat伺服器CPU使用率過高

tomcat要執行依賴於JDK，tomcat伺服器的CPU使用率過高，大多都是因為部署的web程式的問題。 一、現象描述 在一次線上環境，前臺訪問頁面的速度越來越慢，從瀏覽器F12中看到發出的請求都是pengding的狀態。 二、排查過程 我這裡tomcat部署在linux環境中。下面的排查過程均在linux

cpu佔用過高排查

top命令是Linux下常用的效能分析工具，能夠實時顯示系統中各個程序的資源佔用狀況，類似於Windows的工作管理員 內容解釋： PID：程序的ID USER：程序所有者 PR：程序的優先級別，越小越優先被執行 NInice：值 VIRT：程序佔用的虛擬記憶體 RES：程序佔用的實體記憶體 SHR：程

java web伺服器cpu佔用過高的處理

平時專案中有時遇到cpu過高的情況，在此基於自己有限的經驗寫個分享，此處的伺服器都是基於linux平臺。 cpu的佔有執行緒型別總的來說分為兩種： us ：使用者空間佔用CPU百分比 sy ：核心空間佔用CPU百分比 一般來講CPU us高的解決方法： CPU us

如何解決伺服器CPU使用率過高的問題

一、找出是因哪個站點導致的？   1、執行cmd; 2、輸入命令 iisapp –a ，如下看到連線池對應的PID，則找到是因 appPool estate站導致的；   二、如何從該站中找出問題，是由於什麼原因？ 1、善用伺服器效能跟蹤工具： 如上圖： A、Number

效能優化-CPU佔用過高問題排查

1. 效能優化是什麼？ 1.1 效能優化就是發揮機器本來的效能 1.2 效能瓶頸在哪裡，木桶效應。   CPU佔用過高 1、現象重現 CPU佔用過高一般情況是程式碼中出現了迴圈呼叫，最容易出現的情況有幾種： a)遞迴呼叫，退出機制設計的不夠

排查定位由死迴圈引起的cpu負載飆高或者死鎖

在linux下： linux的top命令可以檢視程序的pid，我們找到java程式的pid， 然後執行 top -Hp pid 就可以檢視到這個程序下執行緒的執行情況。 這樣粗略可以看到哪些執行緒比較繁忙，這時候就用到jdk自帶的小工具jstack(官方文件或者自行 百度)。 我們

MYSQL "ORDER BY rand()"的坑--容易導致機器負載、CPU佔用過高

在一次微信砍價活動營銷中，使用了4核16G10M頻寬的伺服器支撐業務，本來這個配置跑個PHP+MYSQL+nginx肯定輕輕鬆的事情，可是隨著活動的高潮，併發數一高，機器負載核CPU一下子就達到100% 始終找不到原因，只知道是mysql分配的記憶體不夠，一直給它加，但是重啟m

如何排查CPU佔用過高以及常見的幾種情況

在最近上線過程中遇到cpu佔用率過高問題由於問題已解決,此時僅重現操作方法1.先用top命令,找到cpu佔用最高的程序 PID  如上圖2.再用ps -mp pid -o THREAD,tid,time   查詢程序中,那個執行緒的cpu佔用率高 記住TID3.jstack

jvm cpu過高排查實戰

雙十一了，頭一天晚上10點左右收到阿里雲cpu超過90%簡訊報警。 第二天上班了，開始處理,步驟如下： 1、top找出cpu高的java程序號9592 2、top -Hp  9592檢視cpu佔用time最高的執行緒編號28178 3、執行 printf "%x\n" 28

一次線上機器load負載過高報警問題排查及其後續處理

問題來源：從3.14號開始陸續收到線上一臺機器的負載過高報警 問題排查 : 於是對gc、堆記憶體、load負載、cpu使用情況等進行了統計分析。 gc時間圖示 堆記憶體使用情況： load負載 cpu使用率 通過以上對gc的統計，

CPU load過高產生的原因及排查

之前面試被問到，造成CPU load過高的原因有哪些？如何快速排查其原因？ 開一貼，總結該相關知識 什麼是cpu load 值 top命令中顯示的load average即為最近1分鐘、5分鐘和15分鐘的系統平均負載。 系統平均負載被定義為在特定

cpu load過高問題排查

load average的概念 top命令中load average顯示的是最近1分鐘、5分鐘和15分鐘的系統平均負載。 系

kubelet CPU 使用率過高問題排查

# kubelet CPU 使用率過高問題排查 ## 問題背景 客戶的k8s叢集環境，發現所有的worker節點的kubelet程序的CPU使用率長時間佔用過高，通過pidstat可以看到CPU使用率高達100%。針對此問題對kubelet程序的異常進行問題排查。 [![DcfCjI.png](ht

tomcat內存占用過高排查小結

java tomcat 內存泄漏 假設tomcat進程PID為16818確認是不是內存本身分配過小：jmap -heap 16818找到最耗內存的對象：jmap -histo 16818 （帶上:live則表示先進行一次FGC再統計，如jmap -histo:live 16818）導出內存轉儲快照

postgresql某進程占用cpu資源過高，降不下來

ted 影響 字段 出了 reat con sha 應該 effect 由於是開發階段，所以並沒有配置postgres的參數，都是使用安裝時的默認配置，以前運行也不見得有什麽不正常，可是前幾天我的cpu資源占用突然升高.查看進程，發現有一個postgres的進程占用CPU都

kipmio佔用cpu資源過高

雖然這是一個利用空餘的CPU資源進行一些介面自動調節的任務，但看著佔那麼多的資源還是怕出意外。 可以臨時降低 echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us 永久減低 編輯（沒有自行建立）/etc/modprobe.d/i