分类：
2010-01-21 11:12:14
weblogic系统性能调试
java平台的优化调试以前没有太多经验，通过周一一夜的摸索，在有weblogic调试经验的朋友一起研究下，对weblogic平台有了进一步的理解。
昨天的优化调试主要在以下一些方面进行。
1。系统环境方面。
在服务器系统中一般都会有一些默认限制，如对网络连接、每用户打开进程等，在产品运行时需要保证系统的各方面设置不会限制应用的规模。在linux中，可以通过修改/etc/security/limits.conf来设置用户进程的限制数，默认是1024。
通过测试也发现采用apache负载+weblogic集群的模式能够达到最大的性能，通过apache来分担HTML的访问，而且也便于http日志的统计分析。
2。weblogic集群和节点配置。
weblogic server有两种模式，一种是开发模式，一种是产品模式。前者用来输出较为详细的调试信息，而且修改java脚本无需重新部署，但是效率较低；后者效率较高，但是修改了应用脚本程序需要重新部署应用。作为成熟的应用发布，使用产品模式能够提高更强的性能。
在JDK的选择上，weblogic有两种JDK供选择，一种是Sun的JDK，另外一种是Bea的jrockit。按照bea的网站的说明，sun jdk提供更好的兼容性，而使用jrockit可以提供更好的性能。作为weblogic集群我全部采用jrockit作为JDK环境，以达到更高的性能。
在默认启动情况下，jrockit启动时为其窗口配置的内存大小比较小。注意weblogic的启动内存配置-Xms
weblogic的kernel设置是非常重要的，可以通过console来进行。主要包括一下一些参数：
Queue Length 指定指定在队列中同时等待的最大请求；
Thread Count 指定weblogic为队列分配的进程数
Threads Maximum 指定weblogic能为队列分配的最大进程数
Threads Minimum 指定weblogic为队列分配的最小进程数
Threads Increase 指定进程数增加的幅度
一味的增加队列长度和进程数并不是一个明智的即决办法，这需要综合衡量。一般来讲内存资源丰富可以增加队列长度，进程数的增加要和数据库连接性能一起考虑，在测试中我们发现，将Thread Count、Threads Maximum、Threads Minimum设置为同一个数值，固定线程数是个很好的选择，可能这样对于weblogic的内存释放与回收比较好。
weblogic对于内存是非常敏感，保持稳定的最佳内存回收机制是提高weblogic性能的重点，这点可以通过console的内存使用曲线来监控，以上所有的weblogic配置最终要达到的就是高效的内存回收。
3。数据库与连接池配置
oracle数据库和weblogic的连接池的配置需要连带考虑，但是所有weblogic节点的连接池最大连接数之和不能大于oracle的最大线程数。
例如，我们修改oracle的process为200，链接池的Maximum Capacity即最大线程数为40，因为连接池部署到了4个节点，所和160小于整个数据库的进程限制。
如果数据库系统环境可以提高可以修改oracle的部分参数来给与更高的处理能力，如调整默认的SGA和PGA、使用更高的IO性能硬件来存储数据库文件，可以通过vmstat来观察，逐步调整。
4。性能的协调性和同步
经过这次调试最大的收获就是在系统调优的过程中要注重整体的协调性和同步，单纯提高某一方面的参数并不一定能解决整体性能，甚至还会带来更大的问题，同时还须从网络、系统、应用和程序多个方面来共同调试和优化。
5。逐步找到临界点
weblogic平台没有一个绝对的设置规格，java平台虽然对内存要求较高，但是在你划定的内存范围内还是具有很强的伸缩性能。要达到最佳性能需要不断的去找到最佳的临界点。
这次做优化调试的另外一个收获是，须一点点的测试找到整体系统性能的临界点，在现有硬件平台的基础上达到最大的性能，同时了解提高性能拓展应增加的设备。
经过一夜的优化测试之后，9000条并发测试数据weblogic集群已能够基本成功处理并写入数据库，失败率低于0.3%，还是可以接受的。
经过这次又有了对产品测试新的认识和理解，以前对产品测试一直不太关心，其实测试工作本身就涉及到了网络、系统、应用和开发等多个方面，一个良好的测试工程并不亚于开发构建工作，其中设计到的知识面需要相当宽，而且需要一定的深度，同时还有良好的整体分析能力。
窗外冷雨寒风，身上短袖未添衫，值得
