美国棒球比分网:Java快速開發平臺

棒球比分大小怎么算 www.355548.live www.fastunit.com

  BlogJava :: 首頁 :: 聯系 :: 聚合  :: 管理
  23 Posts :: 0 Stories :: 273 Comments :: 0 Trackbacks

內存問題錯綜復雜,本人水平也有限,淺薄之見僅供參考。

一、GC監控

GC日志記錄了內存使用和回收狀態,出現內存故障時,可作為分析排查手段。

1. 啟用GC監控的方法:增加java啟動參數-verbose:gc,輸出信息的樣例:

? GC?135:?total?final?references?4390;?cleared?final?references?8.?
GC?135:?total?phantom?references?0;?cleared?phantom?references?0.?
GC?135:?total?old?soft?references?0;?cleared?old?soft?references?0.?
GC?135:?total?JNI?global?weak?references?0;?cleared?JNI?global?weak?references?0.?
GC?136:?starting?collection,?maximum?allocation?reached.?
GC?136:?live?objects?1081046;?collected?objects?6038;?collected(KB)?558.?
GC?136:?queued?for?finalization?0;?total?soft?references?113;?cleared?soft?references?18.?
GC?136:?current?heap(KB)?716784;?current?threshold(KB)?262144.?
GC?136:?collect?(milliseconds)?1314.?
GC?136:?current?cycle?allocation(KB)?0;?previous?cycle?allocation(KB)?532.?
GC?136:?total?weak?references?1321;?cleared?weak?references?0.?

2. 將GC日志輸出到文件:不同JDK設置的參數不同,參考JDK官方文檔
?? SUN:-Xloggc:filename (例如:-Xloggc:D:/gc.log)
?? IBM:-Xverbosegc:file=filename 或 -Xverbosegclog:filename
?? HP?:-Xverbosegc=filename??

3. 如何設置Java啟動參數:有多種方式,以下各舉一例
?? Tomcat:在catalina.bat的“set JAVA_OPTS=%JAVA_OPTS% ”后設置
?? WebLogic:在startWebLogic.cmd的“%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% ”后設置
?? WebSphere:進入管理控制臺,應用服務器->進程定義->Java虛擬機高級定義

4. GC日志的圖形分析工具:HP的jtune


二、內存問題描述

典型現象是系統運行一段時間后,報OutOfMemoryError錯誤、頁面非常慢、不響應或完全不再接受請求,而此時通過觀察JVM內存,發現內存急劇上升到最大值并居高不下。

這種問題出現后,往往很棘手,通常是由于應用程序不合理造成的,而不合理程序或內存泄漏的源頭可能并不明顯。本人的一次經歷是,經過十多天各種測試手段后,最后確定問題是由一處String累加引起的,改成StringBuffer就解決了,可見,忽略“小問題”往往會帶來大麻煩。

三、分析手段

1. 分析GC日志、系統日志
2. 程序中設置監控斷點
3. 盡可能重現故障并同時監控JVM內存,找出引起內存急劇上升的規律
4. 檢查關鍵程序或頻繁使用的工具類的合理性

四、解決手段

1. 主要從程序入手:降低內存使用量;字符串累加時以StringBuffer代替String;隨時釋放不再需要的對象;SQL優化及避免頻繁取出大量數據;Session中不要放大的數據。。。
2. 據WebSphere和WebLogic官方建議:通常情況下JVM的Heap最小值和最大值可設成一樣(根據實際情況調整),可取系統內存的25%-75%,保證JVM有合理足夠的內存大小
3. 應用服務器的其他優化措施

五、應急措施

1. 不設定JVM的最大Heap上限
2. 程序中判斷內存吃緊時執行Runtime.gc()強制垃圾收集,此方式比自動收集徹底,可一定程度上改善內存利用效率
3. 在不影響業務的情況下,定期重啟應用服務器

posted on 2008-01-23 13:31 FastUnit 閱讀(7080) 評論(9)  編輯  收藏 所屬分類: Java

Feedback

# re: 如何監控GC及內存問題解決方案 2008-01-23 13:42 BeanSoft
非常不錯!  回復  更多評論
  

# re: 如何監控GC及內存問題解決方案概述 2008-01-23 15:28 dennis
據WebSphere和WebLogic官方建議:JVM的Heap最小值和最大值設成一樣,這個說法是誤導人的。不同的jvm的垃圾回收算法不同,甚至同一個jvm也有不同的GC算法,還是要根據實際情況調整。  回復  更多評論
  

# re: 如何監控GC及內存問題解決方案概述 2008-01-23 15:48 FastUnit
@BeanSoft
感謝老大的鼓勵!

@dennis
這一點我沒有太多經驗無從判斷,不過這確實是多位官方專家在現場給予的建議,應當是針對他們自己的產品而言。為求準確,我加上一句“通常情況下”,感謝指正!
  回復  更多評論
  

# re: 如何監控GC及內存問題解決方案概述 2008-01-23 18:19 BeanSoft
呵呵 老大不敢當 不過 JVM 參數設置的確有很多貓膩呢。。。 在以前公司搞過一陣子 Weblogic JVM 調優  回復  更多評論
  

# re: 如何監控GC及內存問題解決方案概述[未登錄] 2008-01-23 20:25 吳開春
在產品運行中,僅僅為了捕獲可能的泄漏問題而打開GC日志并不值得。

相對而言,在系統一個版本完成時,用內存檢查工具來進行測試。在開發過程中,解決一部分泄漏問題。性價比要高一點。

實際運行過程中,如果產生泄漏必定是某一過程重復積累到一定程度導致的。往往需要結合日志從發生問題的邊界點檢視代碼,再努力重現問題來解決。
  回復  更多評論
  

# re: 如何監控GC及內存問題解決方案概述 2008-01-24 10:27 怎么羨慕天空的飛鳥
非常感謝,  回復  更多評論
  

# re: 如何監控GC及內存問題解決方案概述 2008-01-24 15:52 FastUnit
@dennis,BeanSoft
看來還得加上dennis的一句話:根據實際情況調整。  回復  更多評論
  

# re: 如何監控GC及內存問題解決方案概述 2008-01-24 15:55 FastUnit
@吳開春
完全贊同,無論內存問題還是其他問題,越早暴露越好,也需要良好的編程習慣避免問題的產生。對于大型系統而言,在運行期間出問題往往是致命的。  回復  更多評論
  

# re: 如何監控GC及內存問題解決方案概述 2009-06-15 10:04 ufo
(web server軟件)UFO不會出現一個字節的內存泄漏和一個線程的不能回收,使用UFO做Web Server的好處是網站能做得很穩定,永遠也不會自己down掉;UFO在托管機房丟包率很高、遭受Hacker攻擊、互聯網 骨干網被黑等惡劣的環境條件下仍然能很好地運行;UFO在對付Hacker方面(防Hacker弄down和Hacker抓取不該訪問的資源)也有足 夠措施。
另外,UFO幾乎不會進行垃圾回收,消耗CPU很少,在普通的PC Server上用UFO運行網站,平時CPU占用率<0.1%,最多時也不會超 過5%。您知道,JVM的垃圾回收會導致大量的運算,消耗很多CPU,從而導致Server的負載能力和響應速度下降。UFO在對象管理方面采 用了很好的機制和算法,做得很出色。用UFO運行網站,可以一直保證高負載能力,快速的響應速度和低CPU消耗。發布網址:www.gm365.com
  回復  更多評論
  

{ganrao} 排列三 意大利pk10怎么玩能 安徽快三哪里下载 合理的家庭资产配置图 快3开奖内蒙古结果 内蒙古十一选五开奖五号的 湖北快三中奖金额 期货公司配资一万多少钱 贵州11选5遗漏数据 河南体彩481今天开奖号码 秒赚app里德国赛车 详解1000炮捕鱼机技巧规律 十一运夺金出号预测号 湖北福彩30选5开奖手机版 双色球旧版全部超长走势图 甘肃11选5走势分部图