测试是一门武功,流程是套路、工具是武器,有简单的花拳秀腿,也有深奥的少林武功!测试好比战争,知己知彼,方能百战不殆!测试好比破案,精心推断,方能柳暗花明!有人说世界不缺少美,而是缺少发现,我看:其实软件不缺少问题,而是缺少发现!以精深的少林武功、用艺术工程的眼光、战争破案的缜密思维去发现软件世界“美”吧!

发布新日志

  • 系统性能问题实例

    2008-02-20 00:04:18

    服务器前后台均为SUSE LINUX9.0 双CPU 8G内存 tomcat服务器

    tomcat使用最小512M 最大1024M内存

    最大进程数为200

    使用spring连接沲,最大连接数目为150,最大空闲数为120。

    数据库为oracle9i   AIX 四CPU 4G内存

    最大连接数为300

    使用LR进行性能测试, TPS在50的情况下

    问题1  性统占用内存达到100%,

    问题2  服务所后台提示"no more process",

    问题3  服务器前台提示"open too many file"

    问题4  某存贮过程执行时间达到了5秒钟

    问题5  数据库所在机器CPU达到100%

    解决过程: 因为有前后面服务, 先排除前后台通信问题. 因为是SOAP进行通信的, 所以建两个工程只进得简单的SOAP协议交互.

    结论,TPS达到300, 前后台均在正常范围之内,可以说明SOAP并没有问题.

    1、检查代码,发现记录日志模块每次都new一个对象出来, 没有释放。 造成内存占用过多,同时也打开了很多系统线程。

    修改为单实例模式。

    问题1及问题2解决。

    2、检查代码,发现在写文件时,没有关闭文件连接。

    关闭连接。

    问题3解决

    4、在该存贮过程中发现有SQL进行了大表的全表扫描。

     对该表根据些SQL建立合适的索引。

    问题4解决

    5、在检查了所有SQL都进行了索引查询, 但TOP5事件是还是有序列读占很多资源。

    索引不合理,不应当使用联合索引, 这样大大影响了数据库性能。 对索引分开建立。

    问题5解决

    另外,如果TOMCAT没有足够的内存空间,会导致TOMCAT挂掉。数据库连接沲配置过小也会导致系统与数据库之单频繁建立连接,使数据库变化用户数过多,影响性能。

    维护一个连接大约需要3M的内存,可以根据实际情况配置。 但够用就好,不是越大越好,维护这些连接也是有资源开销的。

    可以发现,从配置到代码, 从代码到SQL,只要有小小的出入,都会造成严重的性能问题

数据统计

  • 访问量: 2797
  • 日志数: 5
  • 建立时间: 2008-02-19
  • 更新时间: 2008-05-03

RSS订阅

Open Toolbar