与恐龙共舞 1. 内存报警

不要想歪了, 这个恐龙是那些古老的庞大项目. 有多大呢?
最新鲜的数据, 正好在做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也不能乱修. 弄不好要影响已有客户.
人世间最大的痛苦不是找不到问题, 也不是找到问题不会修正问题, 而是找到问题, 可以修正, 却不能修正...