【IT168 技术文章】

    昨天正在培训的时候，有人给我打电话，告诉我门户上不去了。很快，厂家有告诉我，门户的服务器起来后，内存消耗的非常快，很快进程挂死后退出。

    从现象上看，非常容易就知道是websphere的内存溢出。我问厂家有没有生成javacore，厂家的回答是没有生成（后来知道是因为他们禁止了javacore的生成）。但是根据之前的经验分析，必然是溢出造成的。

    这种门户基本上稳定运行，基本上能运行1-2周才会出现问题一次，这次频繁的挂死，谁都没想到。

    我问了下，系统没有做任何升级，原因暂时找不到。

    基本上从下午开始，门户一直都上不去，各地开始反映情况了。

    幸好手头有一个2950做测试，性能超过目前正式环境的机器，马上通知厂家先把/opt/IBM 目录删除日志文件后做一个tar包。我忽略了，应该告诉他当时tar的时候应该加参数z，结果他们tar包出来，文件一共4.4G，两个服务器之间互传，结果发现网络条件不好，中间找了个本地的pc做中转。

    晚上培训完赶回公司，发现开发在做静态页面，准备在恢复失败的情况下，先把静态页面挂上去，嵌入一个登录框。

    我到中转数据的pc上看了下，文件在本地已经收完了，我看了下大小，4.4G着实吓了一跳，不过考虑他们运行了很长时间，有很多用户图片还存在，这个大小倒是合理的。去idc，转机器恐怕还耽误些时间，我就偷懒了，直接用ssh拷贝tar包到备用机器上。需要53分钟，就在那里等，结果40分钟过去了，跳出来一个conn连接断开的提示，之前的工作都白做了。

    没法子，又找了个移动硬盘，结果发现硬盘是fat32的。我记得好像fat文件系统最大支持的是4g，这个有点悬，这边先拼一下吧，向磁盘拷贝文件的同时，又找新的硬盘，半天没找到新硬盘，拷贝到移动硬盘没想到成功了。

    看了下大小，3.96G原来windows计算方式按照1024来计算，阿弥陀佛，真是幸运，就是这40M救了。马上拿着移动硬盘，跑idc，找机器半天，终于在同事帮助下找到了机器，然后赶紧在新机器释放，运行。结果应用服务器起不来，心里就开始打鼓了，能不能修复。还好当时非常冷静，看了下systemout，发现里面有大意如下的一段文字：“root用户验证失败” 奇怪了，was也验证root用户？马上让厂家把机器root的密码改回原来机器的密码，很让人欣喜，可以启动了。立即搬到2楼机房，把原来的网线切过来，系统跑起来做测试。检查了一下jvm的内存配置、本地连接池、webcontainer这些参数，基本没什么问题。

    如果这次不偷懒，可能恢复能提前一个小时完成。备份机器非常重要，关键系统上一定要跑集群。虽然集群可能麻烦点，但是最后出现的时候，业务无论如何不至于完全中断。

    ps：本次恢复还有一个意外的发现，那就是在linux as3上的应用打包可以在as4上直接运行，但是as4上的应用服务器软件整体打包在as5上就无法运行了。

    又关注了一下整个应用的数据库环境，oracle没做备份。这个也是个问题，需要提醒ap赶紧把这个解决掉，按照现在的数据量，export完全可以，并且应该在其他机器上做一个完整冷备份。