不要想歪了, 這個恐龍是那些古老的龐大項目. 有多大呢?
最新鮮的數據, 正好在做sccs轉svn, 大概有8萬多次提交. 大概八年的項目.
庫有1G左右,都是代碼和代碼歷史..

這里記錄一些與恐龍共舞的經驗, 不愉快的記憶最容易被遺忘, 還是記錄一下.

1. 內存報警
這個報警是個老問題, 很多客戶都有這個問題, 是個老大難. 以前有人改過, 貌似沒用. 輪到我接手, 硬著頭皮上吧.
首先看代碼....暈....這個代碼風格, 不, 應該說整個項目都是, 文檔幾乎沒有了. 有也對不上, 在無數的改進和bug fix以后幾乎慘不忍睹. 慘點還不算, 還不能format代碼, 因為代碼變化太大, diff出來沒法看. 這個不同的縮進, linux, windows, vim, eclipse下不同的工具下出來的代碼真是百花齊放. 后來我找到訣竅. format之后再還原.
代碼很暈, 誰知道哪段代碼把內存的肚子搞大了....還是先看現象吧.
現象機器上還好有不少log, 長長的一串數據...暈啊都是告警, 要么high, 要么crtical...性能監控居然沒有內存和cpu采集....

暈了一天以后, 還沒解決問題. 再看log, 先看看告警和時間的關系吧:
一個告警是三行, 似乎不能直接進excel畫圖. 還好告警之間是兩個\n, ultraedit, 替換兩個\n為特殊符號, 然后替換一個\n為\t, 再把特殊符號替換成\n, 笨辦法, 湊合吧.
進了excel, 很好, 畫三點圖, x為時間, 縱軸high為1, critial為2

曲線居然是長城形狀的?!偶爾會有烽火臺, 我k. 原來這么壯觀 .
數據太多, 曲線拉寬......無限寬以后, 遠看長城鋸鋸齒, 近看長城....是幾個點!

越來越詭異了, 十分鐘一個城垛, 每個城垛大概6分鐘, 里面有大概6個點左右.
好了, 這個現象超級詭異, 再研究一下系統的內存吧.

=============
內存研究: jdk1.6現在帶了一個visual vm, java寫的, 配合數據采集工具, 能做內存長期監控, 能做heap dump. 另外一個近親是netbeans, 功能非常類似. eclipse的tptp也能干這個, 還有幾個商業軟件, 咱們就不盜版了. 因為在solaris上面, tptp沒現成的可用.就visualvm吧, dump內存發現很多意外的東西, 這個就不多說了, 時間長了這些玩意還能被回收掉. 暫時忽略. 開始很多人都懷疑jvm內存泄漏. 監控了很久發現垃圾回收很正常, 空載的時候大概一個小時回收一次, 出現大鋸齒循環. 貌似正常.

負載很重會怎樣? 鋸齒變陡峭, 很快就回收. 頻率在十幾分鐘吧. 怎樣? 聯想到什么?

=================
OK, 暫時猜測, 負載重了就告警, jvm垃圾沒來得及回收告警就升級.
好, 再鉆進代碼垃圾中找找, 哦, 果然, 這個代碼很有趣, 如果剩余內存少到一定比例, 開始log, 再高的話high告警, 再高就critical告警. 檢測周期大概一分鐘.

怎么修正? 這似乎是垃圾回收的正常行為. 那告訴jvm,你必須把內存控制在多少以內? jvm好像不鳥你. k, 這種內存level告警也過于想當然, java內存用多少都有可能啊, 只要內存沒超出, 最后正常收回去就完了嘛.
這里也不是完全絕望的, java7會有更好的垃圾回收機制, 說不定將來能用. 現在, 修改垃圾回收機制, 采用新一點的, 漸進收集, 這個曲線出來就像一個大牛市, 里面有很多小震蕩, 逐步走高, 然后再來個大熊市...
另外, 該進內存檢測, 提高最大內存, 內存在將要告警的時候強制回收一次. 加大負載后因為總內存已經增加, 不會造成特別頻繁的垃圾回收.

OK, 睡覺了

還有點事情, 內存里面的確有垃圾, 算了吧.有空再收拾. 成熟的產品有bug也不能亂修. 弄不好要影響已有客戶.
人世間最大的痛苦不是找不到問題, 也不是找到問題不會修正問題, 而是找到問題, 可以修正, 卻不能修正...

總結

以上是生活随笔為你收集整理的与恐龙共舞 1. 内存报警的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。