关于性能诊断和性能优化的方法和实施案例

最近做了不少关于性能诊断和性能优化的项目, 感觉就是想医生一样,在给系统看病,  下面是一个例子,和分析过程.

 

 

 

 

课题背景	被保险人清单导入功能： 1.     业务人员反映前台处理效率太慢； 2.     大数据量的被保险人清单导入无法从前台完成导入； 3.     性能迫切需要提升。
研究目的	1.     提高清单导入性能和效率； 2.     支持大数据量的被保险人清单导入。
课题要求	1.     提升被保险人清单导入效率； 2.     支持十万条数据量被保险人清单导入。
研究环境	研究环境拓扑图：

服务器详细配置： 服务器名 机器型号 IP地址 Memory CPU 系统版本 软件版本 Tuxedo Server Rx6640 10.32.84.5 128G 8 HP-UX B.11.31  Tuxedo 8.1 Informix Server Rx7640 10.32.84.4 64G 8 HP-UX B.11.31 Informix 9.4 终端服务器 虚拟机 50.1.51.46 4G 4 Windows Server Windows 2000 短险系统版本是SLBPSv1.5.05，数据使用了河南分公司的真实业务数据，导入的清单是人工批量生成的测试数据。

在联合实验室独立的实验环境中，采用系统性能数据的监控分析，问题诊断的层次分析法、瓶颈定位和根本原因查找等方式，最终达到系统优化的效果。 1.     性能数据监控 在实验过程中，通过Glance和OVPA对系统性能监控，后台服务器未见异常情况，Informix服务器和Tuxedo服务器的CPU、内存、IO等资源正常，初步判断各种资源的运行状态良好。因此进一步采用问题诊断的层次分析方法。 2.     问题诊断的层次分析 瓶颈层次分析法 采用层次分析的方法，导入1000条数据耗时900秒，即每处理一条大约要0.9秒。通过对后台Tuxedo服务的监控（tmadmin command），实际处理时间是0.09秒，相差10倍。下面是Tuxedo服务器处理时间： $ txrpt<stderr SERVICE SUMMARY REPORT SVCNAME         10a-11a         TOTALS Num/Avg         Num/Avg --------------- --------        ------- GETTIME         6008/0.00       6008/0.00 CSS_CHKRIGHT    1002/0.00       1002/0.00 csi_01          1002/0.01       1002/0.01 csb_040273      1000/0.09       1000/0.09 --------------- -------         ------- TOTALS          9014/0.01       9014/0.01 从而推断性能瓶颈主要在系统前置到Tuxedo服务之间。清单导入层次分析结果见下图。 3.     瓶颈定位和根本问题分析 通过层次分析，基本把问题定位到前置机和Tuxedo服务器数据通信的范围。进一步对应用代码（短险系统中的cbs_0422_cfi_040273）的分析，发现程序处理的逻辑是每发送一条数据执行一次tpterm（），即每次发送一条数据都要断开链接，再新建链接的动作。这样大大增加了程序的开销。

1.     优化内容 修改短险系统应用代码cbs_0422_cfi_040273.cpp，注释掉断开链接函数tpterm（）。 原代码如下： #ifdef DEBUG_FLAG        (void)userlog("operation succeed !/n");  #endif            tpfree((char *)lFBFRp_obuf );            tpfree((char *)lFBFRp_ibuf);             tpterm();    return 0;} 修改后代码： #ifdef DEBUG_FLAG        (void)userlog("operation succeed !/n");  #endif            tpfree((char *)lFBFRp_obuf );            tpfree((char *)lFBFRp_ibuf);                              /* comments out for performance by hp */            // tpterm();    return 0;} 2.     实验数据 通过对终端程序处理逻辑进行修改的优化建议。减少数据建立链接和断开链接的次数，有效降低服务调用次数，从而提高工作效率。 通过修改Tuxedo链接方式的方法，进行了三组实验，分别导入100条、1000条和10000条数据，所对应的执行时间。       导入数据（条） 执行时间（秒） 100 1000 10000 优化前 346 2391 18972 优化后 48 510 4121 效率提升倍数 7.2 4.7 4.6 由于100条的数据量较小，效率提升倍数可以忽略不计。总体来说，优化后比较优化前效率提高4倍多。优化前后的数据导入时间比较见下图。

此次优化的主要成果： 1.     短险系统的被保险人清单导入的性能提升4倍多； 2.     优化对系统后台和业务操作无影响，程序上的修改代价很小； 3.     是一个可很快落实和推广的研究成果。

在大数据量时，终端服务器报错，在执行导入100000条数据时，报overflow 错误，导入到32766条时，客户端报内存溢出错误，如下： 通过对客户端内存情况监控分析发现，在导入的过程中，客户端内存不断增加 从490M一直增长到1.9G。下图为刚开始导入7475条数据时内存为803M，随着导入数据的增加，内存持续不断的增加。 根据推断，数据是先被读进客户端内存，完成提交才释放内存。如果终端服务器内存较小，支持3万以上的数据导入就比较困难。 根据上述实验数据，我们提出建议： 1. 修改数据导入程序内存管理逻辑，数据提交后就释放所占有的内存资源。 2. 精确计算每条清单数据的大小，把程序为每条数据申请的内存空间降低到最低，节省不必要的内存浪费，从而使导入的数据量更大。

1.   清单数据导入功能优化已取得阶段性成果，成果已经得到相关部门的确认和认可，处理效率提高4倍多； 2.   由于内存溢出，数据最大的导入量是32766条，但预计在修改数据导入程序内存管理逻辑后，导入10万条数据的目标能够完全实现。 3.   由于时间较紧等因素，其中部分优化建议还待开发人员做进一步的程序修改和测试，但在大数据量的导入上找到了问题根本原因，并给出了明确的建议。