記錄處理那次系統性能故障的過程


那次為了下載jprofiler7來測試系統的內存泄露點,還主動去開通了迅雷三個月的會員,雖然錢不多。因為那時候下載這個軟件速度非常慢,才幾K的速度,而這個軟件卻有70多兆,一沖動就花錢開了個會員,心想離線下載也許會快點,結果也沒快多少,估計是國外服務器的問題吧。

后來終於下載完了,把軟件傳到現網的服務器上去又花了一部分時間,因為使用VPN來連接的,速度也不快。

傳上去后,一開始以為能夠直接不用重啟weblogic,jprofiler能夠直接attach到那個weblogic的進程,結果試了好久也不行,無奈只有在weblogic的啟動參數中加了啟動參數:

[plain] view plaincopyprint?

  1. -agentpath:/home/xxxuser/xxxme/jprofiler7/bin/hpux-ia64w/libjprofilerti.so 

直到那台服務器因沒有足夠的內存跑不動了,才叫pso來重啟weblogic,8G的內存都用完了,這是什么內存泄露啊。后來發現系統一開始處理任務的速度越快,服務器也就會死的越快。

加上上面的啟動命令后,就可以直接使用jprofiler連上weblogic的進程查看heap的使用情況,包括每個對象的數量及占用內存空間的大小。

觀察了幾次,就發現有幾個關於Hibernate的對象數量特別多,而且是一直增長的。因我沒用使用過Hibernate,對它的初始化產生的對象及日志沒有足夠的重視,當時還沒有立即發現問題的所在。問了下身邊有用過這個框架的同事,說可能是多次初始化了Hibernate的SessionFactory。

於是查找jpa使用Hibernate的地方,的確發現有一個地方工廠方法每被調用一次,就產生一個SessionFactory對象,原始的代碼如下:

[java] view plaincopyprint?

  1. public static EntityManagerFactory getPlatformEntityManagerFactory() { 
  2.   EntityManagerFactory factory = Persistence.createEntityManagerFactory("xxxDS"); 
  3. return factory; 

不知道當初那些人是怎么寫的代碼,也不考慮一下是否合適,就寫上去了,結果排查這個問題實在是太費勁了,起初還以為是自己模塊的問題。

結果因為這個問題導致了一系列的問題,管理有點混亂啊。

而我除了要處理本身模塊的問題外,還要處理各種各樣的問題,包括性能,功能以及接口調試,而我也只是一個普通的開發。

那時的我感覺真的好累,我是否有必要做這么多啊?


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com