本課程的主旨及目標
•導致應用cpu高的常見原因
•定位問題的大體思路
•定位問題的具體方法
•實際案例
應用cpu高常見原因
•1.程式計算比較密集
•2. 程式死迴圈、死鎖
•3.程式邏請求堵塞
•4.io讀寫太高 （df –h看看磁碟是不是滿了）
•5.自創執行緒沒有限制（執行緒池）
•6.不合理的建立物件，導致頻繁gc
定位問題的具體方法
1.不管什麼情況先用top命令檢視資源消耗，找到消耗大量cpu資源的程序pid，我們一般都是j**a程序排名第一
2.輸入top –p pid 來單獨監控該程序
3.在第2步的監控介面輸入h，獲取當前程序下的所有執行緒資訊
4.找到消耗cpu特別高的執行緒編號（可能會有多個），這裡是6752
5.將第4步得到的執行緒編號6752轉成16進製制是1a60,因為jstack輸出的執行緒棧資訊中，執行緒id是以十六進製制展示的。
6.切換到jbossuser使用者【pid對應的程序使用者，這裡一般是j**a程序使用者】
7.因為沒有jstack這個檔案的環境變數，所以要先export path="$path:/opt/wildfly/openjdk/openjdk-1.8.0_92/bin"
9.通過jstack命令來檢視下當前記憶體狀態，解讀執行緒資訊，定位具體**位置,接下來就是找開發人員確認問題，看這段**是否可以優化。
實際案例
案例一：
定位到cpu過高是io讀寫太高 ,接下來就是找開發人員確認這段**是否可以優化
案例二：
兩個執行緒執行過程中，需要對兩個物件進行加鎖，且加鎖的順序不一致，導致了死鎖的產生，簡單的修復方法是：對兩個物件的加鎖順序一致。
注意：必須有兩個可以被加鎖的物件才能產生死鎖，只有乙個不會產生死鎖問題
案例三：
案例四：
案例五：
1.生產環境heap堆記憶體不斷上公升導致oom，pst環境復現heap堆記憶體不斷上公升。經過分析堆記憶體建立的windq主題或佇列windqqueue、windqtopic方式會快取到連線工廠，快取的物件並不是根據唯一的key去快取，而是直接使用物件的引用作快取，導致jvm無法**這部分記憶體（比如新建同乙個sendoperationtopic的主題object1，object2，object1和object2都會快取到連線工廠）。
2.pst環境百萬資料重試發現棧記憶體溢位，由於遞迴呼叫導致，已將遞迴方法修改為迴圈的方式去呼叫。
結果：修改後pst環境記憶體**穩定，無連線工廠大物件，堆記憶體，無棧記憶體溢位，cpu使用情況穩定。
發現程式異常前通過執行指令，直接生成當前jvm的dump檔案，15434是指jvm的程序號
效能測試應用伺服器CPU高 執行緒dump
效能測試過程中，我們會去監控資源的使用情況,一般監控哪些方面呢？1 伺服器的資源情況 cpu 記憶體 網路 執行緒 2 資料庫 慢查詢 死鎖 3 中介軟體 redis memcache rabbitmq 某日，在測試監控過程中發現，應用伺服器的cpu非常高。分析 應用cpu高，說明程序非常耗用資源，...
應用伺服器cpu,記憶體占用高
自上次解決負載均衡導致伺服器飄紅問題後，房產應用伺服器還是會時不時出現cpu負載過高的問題，並經常在半夜0點後，偶爾也在白天。開始查詢問題原因。1.哪些請求太慢？找出了一些慢請求，結果分析後，找不出導致慢的 而這些慢的請求也是在服務出問題時出現的。2.cpu高時記憶體是正常的，開始懷疑是不是因為jv...
應用伺服器安裝
1.安裝sql server 2008 r2 native client,注意區分cpu是32位還是64位的 2.copy xe2的midas到c windows system32 低版本的midas.dll會報錯 invalid package 3.命令列執行 regsvr32 midas.dll...