河南移动crm系统故障分析报告-基于运维工具

1、关于移动系统问题分析（基于运维分析工具 V5 版本）2009-08-20问题现象：系统经常（特别月底时）出现响应慢，甚至不能响应请求的现象。问题分析：1、系统不能响应请求a)、导致系统不能响应请求最大的一个可能，就是 JAVA 虚拟机内存被消耗尽了。检查了 WebSphere 安装目录，看到有进程堆栈文件和 javacore 文件的生成，这证明系统的确曾经出现过 JAVA 虚拟机内存被消耗尽的情况。JAVA 虚拟机内存被消耗尽最大的可能就是内存泄漏，那么分析来看看系统是否有内存泄漏的可能。通过下面的下面两图分别是 8 月 20 日 12:0020:45 时间段的系统机空闲内存的变化分析图：量和

2、 JAVA 虚拟量还没有超过 120可以看到在系统的期，系统的最高的用户个，但已经差不多把 JAVA 虚拟机内存消耗尽，如下图所示：2、系统响应慢a）、下面以 8 月 20 日 12:0020:45 时间段内的 EOS Server 接收到并处理的请求功能为例，先来分析整个系统处理响应请求功能速度的情况。下图是从 8 月 20 日 12:0020:45 时间段的系统处理的请求中，分析出来的部分请求处理情况（按平均执行时间降序排序）：可以看到，系统中的确存在一些请求功能执行很慢。但同时也可以看到的功能执行还是很快的，如下图所示（按平均执行时间升序排序）：说明并非整个系统中所有的功能处理都很慢，只

3、是存在部分功能处理比较慢。b）、下面再针对系统中部分执行慢的请求功能做进一步的分析。再来看看按平均执行时间降序排序的分析结果：对比每个功能的最短执行时间和最长执行时间，可以分析出有两种情况：1、 有些请求功能并不是每次执行都会比较慢如图中蓝色框出的功能，虽然最长执行时间有 144 多秒，但最短的执行时间可以快到 0.1 秒。这种现象极有可能是因处理的数据量不同造成的。比如查 10 数据和查1000 数据的所消耗的时间肯定是不同的。当然，也有可能是程序中根据不同的数据有不同的分支处理。2、 有些请求功能每次执行都会比较慢如图中红色框出的功能，在处理的 18 次请求中，最快仅 5 秒多，说明该功能

4、一般的处理都很慢。影响功能执行时间的最大可能就是数据库操作，下图是 EOS Server执行时间最长的一些 SQL 操作：的一个 SQL 执行已经消耗了 3、4 秒，那么执行这个 SQL 的功能所消耗的时间可想而知，如果一个功能里多执行几次这样的 SQL 的话，那速度就更慢了。处理建议：1、加大 JAVA 虚拟机内存的配置分析，知道是由于 JAVA 虚拟机内存通过对系统不响应请求造成的。目前系统所配置的内存仅为 1G，建议将最大内存调整到 2G，但最小内存还是保留 1G。配置方法如下：1、选择服务器2、选择进程定义3、选择 JAVA 虚拟机4、配置堆栈大小初始堆大小即 JVM 初始内存大小，最

5、大堆大小即 JVM 允许使用内存大小，不建议两个值配置成一样。2、优化响应时间慢的功能从前面分析知道，系统中存在部分功能执行时间比较慢，这些功能所消耗的时候极有可能是在执行数据库 SQL 操作上，所以建议从优化执行慢的 SQL 来解决整个功能执行慢。优化的方法主要是通过分析 SQL 的执行计划，确定是否可以通过对 SQL 操作的表建索引来提高 SQL 的执行效率。1、先登录 EOS 管理控制台URL 为只能使用 sysadmin 用户。，登录用户名在EOSOperator 表中，2、查看“数据服务状态”中的“统计”信息点击3、将统计列表中的 SQL出来（一般就是查询 SQL）4、在 Oracl

6、e 的客户端工具中分析 SQL 的执行计划将 SQL出来5、找出执行计划中列出的执行 SQL 过程中进行整表扫描的表6、检查进行整表扫描的表结构，确认做为 SQL 查询条件的字段是否建立了索引。如果字段没有索引，建议给字段建索引。当然，查询时做了整表扫描并不一定就是字段没有索引，这仅仅是一种在不改程序的情况下的优化方案而已。如果通过建索引无法优化 SQL，那么只能考虑通过修改 SQL 或者程序来优化了。3、使用 IBMHTTPServer 提高系统速度WebSphere 来的。IBM 建议在应用程序部署在目前系统是直接WebSphere 上时，应该使用 IBMHTTPServer 来，提高效率。IBMHTTPServer 的配置使用方法另外提供文档说明。系统部署的机器上已经安装了 IBM