了解猜想gc的一天

8：48，准时签到，开始新的被‘折磨’的一天
开机
第一时间打开SecureCRT，查看java进程(weblogic)的cpu占用率
42%，纳闷...还没有上班就这么高（平时也不超过50%）
60%,刷了一下屏，坏了，担心...
85%,又刷了一下屏，真坏了
101%,又刷了一下屏，心落地了，停了
打开nohup.out，日期定格在8:48:44，一个不怎么吉利的数字
无奈中重启

打开邮箱，看到了朱兄（www.blogjava.net/zhuyuanxiang）的mail回复，心里非常的感动，说不出的热乎.本来对gc一直不是很了解，朱兄给的资料还是让咱有了大概的认识，在这里也对老哥表示感谢了。
每隔30分钟取出一份gc.out,用hpjmeter进行分析，看到heap一直在增长，到下午2点左右有了第一次old full，之后短时间内出现过15次，而整个heap却没有超过1g，让我很是不解，old明明是1.3g，为什么heap不到1g就full了，会不会jvm私自把old调小了？可不可以通过-XX:NEWSIZE 来指定new，保证old大小不变？满脑子文号，上个hjmeter图吧
summary图
[img]/upload/attachment/52808/f23d1fd6-c65e-34f8-873f-c10687434729.gif[/img]
heap useage after gc图
[img]/upload/attachment/52810/00dde1e7-9d3c-3f51-9dd2-33a02ce1c086.gif[/img]
接下来时间，接二连三的就是2次死停，没有出现old full那个黄点点。
郁闷中...

期间客户反应系统巨慢，考虑是不是可以去掉action调用日志了，记录了一周日志，形成了40万条记录，也没有找出可能出现问题的地方，先去掉吧。
bsca系统调用本地的web service是近期开发的，实在想不出问题，也先停掉吧。
weblogic的http访问日志在11月7号就停了，还是先起来吧，10分钟就记录了5万行，不知道怎么下手了。

晚上修理数据库，重建temp表空间，weblogic服务器加上hpjmeter