开放系统环境监控与解答.doc

开放系统环境监控与分析 6月23日晚进行了P690 LPAR的重大变更，原两个LPAR2是AP双机互备环境，变为AP热备环境，原两个LPAR3是TRCS和MQGW双机互备环境，变为TRCS热备环境；MQ Cluster环境也变为MQ单节点环境，APA访问DBA数据库，ECTA访问DBB数据库。 6月24日的压力测试是在新环境下进行。因为环境的变更，今天的性能监控和分析报告中将不包括APB_NPC_BJ(原系统中APB)和ECTB(原系统中的MQGW)。 6月24日共进行三次压力测试，截止到15：30，有两次压力测试已经完成，第一次在上午10：25开始，为期1小时，15000笔交易；第二次在下午14：30，为期1小时，100000笔交易。第三次在下午16：55开始，为期1个半小时，30000笔交易。三次压力测试的交易大部分是TRCS交易，其它是支付应用交易。 P690各LPAR CPU 利用率 APA_NPC_BJ 上图是APA服务器的支付应用系统运行所占用的CPU比率。 APA服务器在今天的测试中有峰值，从图示和现象看，部分是Tivoli监控所致，部分是由于交易刚开始时的程序调用。从CPU图可以看出，在10：25和14：30分别有两次CPU使用率升高的现象，并在下午进行的300000笔压力测试中，CPU使用率保持在40％左右，相比前两天的结果大有改善。在以后的测试中，我们会继续跟踪AP服务器的使用情况，提供相应的数据分析报告。 上图是APA服务器的操作系统所占用的CPU比率。 APA服务器在今天的测试中有峰值，从图示和现象看，大部分是性能监控工具所致。从CPU图可以看出，在10：25和14：30分别有两次CPU使用率升高的现象，并在下午进行的300000笔压力测试中，CPU使用率保持在20％左右，相比前两天的结果大有改善。在以后的测试中， 上图是APA服务器的IO等待所占用的CPU比率。 APA服务器在今天的测试中有峰值，从图示和现象看，压力测试开始，就造成系统IO一直在读写，并在10：25和14：30分别有两次CPU使用率急升的现象。通过对应用程序和中间件的分析，是由于应用程序和中间件均往系统盘Hdisk0上写log所致。已提交性能优化建议材料，等候总体组的确认。 上图是APA_NPC_BJ服务器对hdisk0即rootvg（操作系统盘；本地盘）的读写操作频率。 从图示看APA_NPC_BJ 服务器在10:20-11:30 和14:00-15:00这两个时间段硬盘的读写操作频率相对较高。这两个时间段内正式压力测试时间, 结合APA I/O 的CPU占用率分析,是由于应用程序和中间件均往系统盘Hdisk0上写log所致。 上图是APA_NPC_BJ服务器对hdisk2和hdisk4即apavg（应用数据盘；shark上共享磁盘）的读写操作频率。 以上两图显示表明，今天的性能测试中hdisk2和hdisk3的读写操作频率很低，并且没有大的异常波动，其峰值在10%左右。按照这种趋势apavg中的应用数据硬盘的读写性能可以满足以后几天的压力测试。 以下是在16:50－18:00的压力测试中对系统性能的跟踪分析。 上图是APA服务器的支付应用系统运行所占用的CPU比率。 APA服务器在本次测试中有峰值。从本图的显示看应用程序CPU占用率平均在25%左右，大部分是性能监控工具所致。 上图是APA_NPC_BJ服务器对hdisk0即rootvg（操作系统盘；本地盘）的读写操作频率。 从图示看APA_NPC_BJ 服务器在本次测试中硬盘的读写操作频率相对较高，出现于上午遇到的相同问题。结合APA I/O 的CPU占用率分析,是由于应用程序和中间件均往系统盘Hdisk0上写log所致。 DBA_NPC_BJ 上图是DBA服务器的ORACLE数据库运行所占用的CPU比率。 DBA服务器的Oracle数据库CPU占用率在该段时间内保持在5％左右。由于CPU使用很低，我们认为DBA服务器在今天这样的压力下不存在峰值问题。从CPU全图可以看出，在10：25和14：30分别有两次CPU使用率升高的现象。 上图是DBA服务器系统本身和监控工具对CPU的占用率。 DBA服务器的系统CPU占用率在该段时间内保持在25％左右。主要由于性能监控工具导致以上结果，可能存在CPU使用不当的情况，在以后的性能测试中将进一步跟踪DBA使用情况。 上图是DBA服务器IO等待处理所占用的CPU比率。 由于DBA服务器数据库读写的IO操作是基于SHARK实现的，从本图可以看出系统IO等待的CPU很少。 上图是DBA_NPC_BJ ORACLE服务器对hdisk0即rootvg（操作系