問題緣起：收到運維同事發來的郵件，說自上次**更新後，cpu使用率上公升趨勢明顯（下圖中紅框部分所示），但**訪問數並沒有增加。
問題排查：是什麼原因導致cpu使用率上公升呢？肯定是某個訪問量比較大的頁面進行了耗cpu的操作，如檔案讀寫、記憶體中的一些複雜運算等。結合上次**更新內容，將問題鎖定在了**詳情頁。主要涉及到讀xml檔案（最大的有2m多）到datatable中，每次開啟頁面時根據datatable中的兩個列值判斷在這個datatable中有沒有，比較嚴重的是讀檔案沒加快取，造成了頻繁的讀檔案，使cpu一直處於忙碌狀態。
找到了問題所在，修改起來就容易多了，增加快取就好了，下面是修改後的偽**。修改之後更新**，cpu使用率又恢復到正常值了（紅框後面的部分）。
///需要特別說明的一點，此次優化在增加快取的同時，還做了乙個小調整，將資料從xml檔案讀到datatable後，為datatable設定了主鍵「dt.primarykey = new datacolumn 」，為datatable設定主鍵可以大大提高select查詢效率（這點有些類似於資料庫中表的主鍵）。因為這次修改了兩個地方，增加主鍵的效率不好用資料說明。但之前做過乙個複雜報表的生成，在記憶體中要對datatable做大量查詢，簡單的增加主鍵後，效率提公升了七八倍。///獲取置業專家列表
//////
置業專家列表
public
static datatable getagentxml()
}if (dt == null);}
}catch
cachemanager.insertcache(cachename, dt, system.datetime.now.addminutes(60));}}
return dt;
}
//////
判斷是否為置業專家
//////
是否為置業專家
public
static
bool checkzyzj(long agentid, long newcode)}}
catch (exception ex)
return iszyzj;
}
快取在程式設計中至關重要，**訪問量小時快取與否影響不大，一旦量上來了，再簡單的邏輯也需要多考慮，平日裡要多有些思想意識在裡頭，才會有預見性，減少上線後出現問題的機率。
記一次Dubbo超時 CPU高負載問題排查
1.問題背景 最近經常有同事反饋我們灰度環境老的交易系統，這裡簡稱trade，dubbo消費者呼叫其他服務超時，因為該專案維護人員眾多，加上灰度環境發布較多，一直沒有排查，然後五一前再次有同事反饋這個問題，剛好有空就準備分析一下引起超時的原因。2.問題排查 2 1 問題描述 大量dubbo服務呼叫超...
一次cpu占用高的定位分析
客戶機器cpu占用較高甚至出現cpu打滿的情況，造流程啟動執行緩慢，狀態更新卡死，嚴重影響使用者體驗。首先觀察使用者機器資源情況，記憶體剩餘40g，jvm記憶體占用10 不到。jps ml 拿到pid之後 jstat gccause pid 發現頻繁fgc,差不多一分種就有一次顯示的system.g...
記一次Nginx負載均衡ip hash會話失效問題
2tomcat nginx ip hash 頁面在載入的時候，提示會話超時，其他頁面都正常。根據現場反饋過來的問題，第一時間問了專案架構，得知是ip hash的策略，第一時間還楞了一下，ip hash怎麼會有會話失效的問題。後來遠端到了現場環境上面，發現提示會話失效的頁面，介面請求返回資料時間比較長...