使用 IBM 性能分析工具解决生产环境中的性能问题

核心提示： 项目背景介绍项目背景：内网用户 500 人，需要同时在线进行业务操作（中午休息一小时，使用 IBM 性能分析工具解决生产环境中的性能问题(2)，晚 6 点下班），生产环境采用传统的主从式，才发现日志中赫然记录有 OOM 的错误，这才引起了项目经理的注意，未做 Cluster ，提供 HA 高可用

项目背景介绍

项目背景：

内网用户 500 人，需要同时在线进行业务操作（中午休息一小时，晚 6 点下班）。

生产环境采用传统的主从式，未做 Cluster ，提供 HA 高可用性。

服务器为 AIX P570，8U，16G，但是只有一半的资源，即 4U，8G 供新系统使用。

项目三月初上线，此前笔者与架构师曾去客户现场简单部署过一两次，主要是软件的安装，应用的部署，测一下应用是不是能够跑起来，算作是上线前的准备工作。应用上线（试运行）当天，项目组全体入住客户现场，看着用户登录数不断攀升，大家心里都没有底，高峰时候到了 440，系统开始有点反应变慢，不过还是扛下来了，最后归结为目前的资源有限，等把另一半资源划过来，就肯定没问题了。（须知增加资源，调优的工作大部分都要重新做一遍，系统级、数据库级等等，这也是后面为什么建议如果资源可用，最好一步到位的原因。）为了临时解决资源有限的问题，通过和客户协商，决定中午 12 点半和晚上 11 点通过系统调度重启一次应用服务器，这样，就达到了相隔几个小时，手动清理内存的目的。

项目在试运行阶段，仍旧有新的子应用开始投入联调，同时客户每天都会提出这样那样的需求变更，如果要的很急的话，就要随时修改，隔天修正使用。修改后没有充分的时间进行回归测试，新部署的代码难免会有这样那样的问题，遇到过几次这种情况，最后不得不在业务系统使用的时候，对应用系统进行重新启动，于是就会出现业务终止引起的数据不一致，还要对这些数据进行修正维护，加大了工作量。期间，应用在运行过程中有几次异常缓慢的情形，由于业务不能中断太久，需要迅速恢复系统投入使用，所以往往是重启一下应用服务器来释放内存。事后检查日志，才发现日志中赫然记录有 OOM 的错误，这才引起了项目经理的注意，要求架构师对该问题进行进一步研究确认。