性能测试细心耐心很重要

1.1.       性能现象

某局空间数据管理系统系统在试运行前期，发现速度特别慢，浏览一个空间图层A，才2800多个面要素（2800条记录），发现竟然耗时达到一分钟，而在普通的台式机器上3秒不到。

运行环境：HP服务器cpu 16核x64 双至强，物理内存为8GB，系统盘可用磁盘40GB。其他磁盘空间在1TB以上，采用磁盘阵列存储。

软件环境：c/s结构，空间数据引擎为arcsde 9.3.1，数据为oracle 10.2.0.3，操作系统为window 2003 sp2 for win 32企业版

1.2.       问题解决过程

进入现场，发现windows操作系统居然是32位，明显和硬件cpu不匹配，因为操作系统是硬件集成商安装的，没有办法立刻解决，先排除是否是系统上层原因。

1.2.1.排除空间数据引擎（arcsde）的原因

使用arcatalog采用sde service的方式连接A图层，速度是相当慢。然后采用直连的方式，直接用oracle的net服务名方式连接，浏览空间数据服务器，发现速度还是很慢。这样可以排除sdeservice的问题，同时也排除了应用程序的问题，问题焦点放到了oracle上面。

1.2.2.排除oracle的原因

检查oracle配置，发现不符合规范的地方比较多：

问题1：数据文件和oracle管理系统文件存储在一个目录下面，影响性能；

问题2：所有空间和业务数据都放在一个表空间中，表空间的文件已经到了32GB（在windwos 32位系统上，最大文件大小为32GB），这样文件的读写都在一个文件上，这将影响到性能；

问题3：发现oracle内存占用才580多MB，而物理内存有8GB，太浪费资源了；

问题4：其他细节性问题。

针对上述问题，先对表空间实行文件拆分，根据数据类型将数据拆分到不同的磁盘，建立不同的表空间，然后重新浏览数据，发现速度没有明显提升。

然后根据oracle内存顾问程序（也可以直接读取v$sga_target_advice、v$pga_target_advice动态性能视图），调整sga大小和pga大小，将oracle内存调整2GB（在windows 32操作系统下，oracle最大内存只能为2GB），保证数据时间改善百分比接近0%，然后重新浏览数据，发现速度还是没有明显提升。

然后采用数据库监控工具spoitlight for oracle，监控oracle运行情况，发现缓存命中率很低，最低只有24%，严重低于oracle缓存命中率可接受的值。

     然后加大共享池的大小，缓存命中率有一定提高，但是性能还是没有大的提升。

难道磁盘出了问题?然后把数据文件移到另外一块逻辑磁盘，重新浏览数据，发现还是很慢，以为磁盘不存在问题（这为后面折腾的时间埋下了伏笔，居然忽视了磁盘I/O，居然没有去监控磁盘，而只做了猜测），难道问题出在操作系统上面？

1.2.3.排除操作系统的原因

     监控系统资源，发现服务器可用物理内存一直在5GB以上，cpu利用率中，没有一个cpu利用率在50%以上的，瞬间利用率在50%以上的都很少，可以断定服务器资源没有明显瓶颈（这里又漏了一个很大的方面，磁盘利用率居然又一次没有监控了）。

重新安装windwos 64位操作系统，重新安装oracle软件和导入数据，发现性能还是没有大的提升。

然后将A图层拷贝到一台笔记本上面（问题就出在这里，只拷贝了A图层，而没有拷贝A图层所在的数据集DataSet，因为图层的存储参数在数据集里面设置的（如精度和容差），拷贝A图层只能检查数据是否存在问题，忽视了影响性能存储因素，问题的魔鬼就藏在这里），浏览，发现速度才5秒不到。问题难道在硬件上面？

1.2.4.查找硬件原因

还过3天要试运行了，项目经理其实比我还急。硬件检查从磁盘开始，往服务器拷贝A图层所属的整个数据集，同时监控磁盘，发现磁盘利用率平均在118%以上（磁盘写入速率在160%），如下图所示：

这样，可以确定磁盘是瓶颈，离问题越来越近了。问题应该在硬件上面，难道刚刚购入才半年的服务器，磁盘已经坏了。打电话给集成商，让集成商参与联合调试，集成商采用硬件检测工具，然后发现磁盘的raid的高速缓存没有开启，一查，原来是raid卡没有安装电池。非常高兴的以为，问题应该差不多了（事情远远没有那么简单）。因为涉及到磁盘更换的问题，需要给硬件提供商一份报告，所以，马上找来另外一台台式机，做对比测试，安装环境，然后拷贝A图层所在的数据集（和前面不同的是，这里拷贝了A图层所在的数据集DataSet，而笔记本上只拷贝了图层A），台式机比服务器的磁盘，平均利用率在20%左右，这个值是有点高，但是还是小于参考值的。

呵呵，磁盘利用率台式机比服务器低了90%（磁盘写入相差140%），心情大爽，满以为找到了瓶颈（就是raid缓存没有开启的问题，实际又错了），然后在台式机上面浏览图层A，台式机速度和服务器好不了太多。

1.2.5.重回软件层面

没有解决问题，一切解释将会是白扯，只知道磁盘是瓶颈，但是还不是唯一的瓶颈，问题重新回到了软件层面。想到原来在一台笔记本上面数据很快，然后在一台台式机上面速度很慢，对比之下，当然想到了DataSet设置的问题了，检查服务器上DataSet设置，如下图所示：

我的神，谁把xy的tolerance值设置成这么大，无语，魔鬼已经揪出了，（后来听说是非故意弄的，据说实施人员在入库过程中出过一次错，可惜没有实施记录，又嵌套了一个细节决定成败的例子，如果早点和项目组说一声，大家就不要这么折腾了）因为sde库中，xy的tolerance值是以整型存储的，tolerance值的精度越大，在转换为整型过程中，就会成为一个非常大的值，这样占用的存储空间也越大，一个面要素有很多个点连接组成，这样在浏览面图层时读取的oracle数据块也会越多，磁盘I/O也会非常大，对于相当大的值类型，相同的几率会很小，所以oracle缓存命中率也会很低。

马上调整设置，将tolerance设定为小数点后面3位，然后重新浏览数据，速度由原来的一分钟提高到3秒左右，性能提高了20多倍，问题终于解决。

1.3.       总结

折腾了快3天，瓶颈终于找到，：

1、             磁盘raid的高速缓存没有开启（硬件集成问题）；

2、             空间数据集的设置不合理（系统配置问题）；

感慨，就是几个字，细节决定成败，要想不折腾，就不能放过细节，其实有几次离真相很近了：

 第一次：当时往笔记本上面拷贝图层时，为什么不拷贝A图层所在的数据集，而只拷贝A图层，否则可以立即做比较分析了。

第二次：习惯监控系统的内存和CPU，不太注重磁盘。在oracle缓存命中率低的时候，应该立即找磁盘原因了。

告诫自己：性能测试，心细不为过。

原文：http://blog.csdn.net/luowangjun/article/details/5728914