性能调优 (完整版).pdf

性能调优 (一) --方案和原则 一.方案演化 历经一周多的性能测试和性能调优工作接近尾声了，这里总结下一周多的进展和调优情况。 首先声明一点，我没有性能调优方面的经验，很多方法都是请教了大牛和网上查找得到的答 案，感觉自己进步了很多。 1.1 封装框架 刚开始对于压力测试采用的自己先的压力测试框架，就是启 N 多线程。然后调用远程服务 器进行压力测试，调用完成后有响应时间等统计信息（见 pc2 性能测试方案篇） 优点：压力测试简单，不需要写太多代码。 缺点：和客户端性能有很大关系，在不同客户端上起线程的速度肯定不一样，这样就导致了 测试出来数据价值不是很大。 1.2 windows 下 Jmeter 进行测试 优点：统计信息全面，较为切近的模拟并发情况。 缺点：由于windows 下客户端性能差别较大，启动线程并没有 linux 下快，会导致发送的请 求数有限，tps 上不去的。 1.3 linux 下 Jmeter 进行测试 优点：较好的模拟并发情况，并发效率较高。 缺点: 使用较为复杂，如果使用 nmon 更需要一定的配置基础。 二.调优原则 1. 贵在坚持，不可以一簇而就，别人的经验通常是针对特定系统，特定环境的，不可以照 搬，不可以不知所以然。 第 1 页第 1 页 性能调优 2. 细节决定成败，调优的准备工作要做好，消除外部因素对测试造成的影响。 3. 可以按照先整体-后部分-再整体的思路进行测试，先整体是看看整体哪块有问题，找出比 较慢的部分进行重点测试和调优，然后再整体测试保证所有应用并发是没有问题。 (二) --方法和步骤 1. webTrace 跟踪数据库 SQL 瓶颈：是否走到索引，是否 sql 执行计划最优等。 2. jProfile 跟踪那块代码消耗 cpu 较多，（jprofile 使用方法见工具篇）。 3. kill -3 进行线程查看，如果有大量 BLOCKED 线程，则说明有问题，如果 RUUNNBLE 的线 程很多都是在执行一样的操作那就说明这部分比较消耗资源，要做优化。 4. apache 调优，对 apache 的各个参数进行调优，最终使 apache 参数对应于当前系统和当 前并发量最优。所以调优的并发量参考数据要经过计算，不可以认为响应时间越快，tps 越 高越好。（经验告诉我们 apache 由于是多进程多线程的，我们采用的是 apache 和 jboss 一 直链接的情况，也不会消耗太多性能，所以还是 apache 好些。其在并发处理方面的能力要 显著高于 JBOSS ） 5. jvm 调优：对于 jboss 配置的 jvm 垃圾回收机制进行调优，让其垃圾回收更加及时高效。 6. 内存使用调优， 使用 jconsole 进行监控，如果内存直线上升，最终得不到稳定，则说明 有可能存在内存泄露等问题。 7. linux 内核调优。这部分难度较高，一般不需要，如果以上步骤不能满足性能要求，考虑 此步骤。 (三) --遇到的问题(数据库) 1. Webtrace 分析 sql 性能，发现 第 2 页第 2 页 性能调优 userPermissionService.listVAccountIdsByUserIdAndProductCode 是数据库未分析数据，执行方案是基于开销的方式，导致执行计划未走到索引。后来是走的 索引，但是仍然较慢。 分析： kill -3 后查看jboss 日志发现很多都在执行listVAccountIdsByUserIdAndProductCode 这个代码 由于apache 线程池都进行了调整，有足够多的等待线程，不太会导致 BLOCKED，这样 runnble 的较多都集中在这个代码上，就说明线程在这里比较占用时间。（用 vi 不要用 tail ） 这个 sql 有问题： select pup.vaccount_id from pc2_user_permission pup where duct_code = #productCode