问题情况：

系统在使用办理过程中出现慢、卡现象，打开处理延缓4-5秒

相关情况：

1． 用户数量：4400用户

2． 数据量：180G

3． 网络：内网

4． 服务器：1台应用服务器+1台数据库服务器+1台备份服务器

5． 中间件：weblogic6.1 SP4

6． 数据库：oracle 10.2.0.4

应用服务器性能情况：

应用服务器网络线路速度：网络应用中的数据传输比较大

weblogic设置：

。。。。。。

"%JAVA_HOME%binjava" -hotspot -ms1024m -mx1024m -classpath "%CLASSPATH%" -Dweblogic.Domain=mydomain -Dweblogic.ThreadPoolSize=500

。。。。。。

weblogic监控情况：

数据库服务器网络应用联网情况：网络应用数据传输较大

oracle参数设置：

。。。。。。

processes = 800

__shared_pool_size = 805306368

__large_pool_size = 16777216

__java_pool_size = 16777216

__streams_pool_size = 0

sga_target = 1610612736

db_block_size = 8192

__db_cache_size = 754974720

db_file_multiblock_read_count= 16

db_recovery_file_dest_size= 21474836480

job_queue_processes = 10

open_cursors = 5000

pga_aggregate_target = 847249408

。。。。。。

思考：

如何从系统整体角度优化调整

计划：

重建索引使用独立表空间

重建索引使用独立表空间的效果并不理想，问题未得到实质解决，在相同的RAID中使用独立表空间不会有效果，如果从索引方面考虑，索引重建在不同的RAID中的表空间、索引表空间的block块使用16K以上可以有效果。

考虑评估主要有几个方面：

程序代码、服务器性能、网络传输、应用配置、数据库配置

程序代码一直使用还是正常，数据量增长影响程序运行？可能性较小

应用配置和数据库配置已经较优了

剩下就是服务器性能和网络传输了

数据库服务器是新的，问题可能性较小；

应用服务器倒是很值得怀疑，应用服务器使用有5年了，配置：Intel® Xeon™ 3.00GHz 2.99GHz，4G内存，而且机房环境较差，灰尘大。

数据量的增大对应用服务器的性能造成了影响和可能性较大，但也无法证明这种推断。

网络传输，只是100M的交换机，也具有提升的空间。

仔细回想了一下，是在数据迁移使用新数据库服务器之前的2010年1月管理员就已经反馈速度有点影响了，当时注意力都集中在数据库服务器上，当时数据库服务器使用的是32位的windows操作系统，当时理解为32位操作系统的影响，认为使用64位的操作系统可以让速度得到改善，现在回想一下，或许当初已经是数据量增大影响了应用服务器的性能，只是当初并没有意识到，

当然，当初考虑整体的方案的时候也是存在疏漏，过多的考虑了数据库服务器，而没有想到应用服务器，道理是显而易见，数据量的增长必定对服务器的性能造成影响，包括数据库服务器和应用服务器，当时应该及时提出应用服务器的采购。

2010-04-28 继续调整

配置weblogic集群和代理，尝试分摊应用服务器的压力，使用了三个服务节点：myserver01、myserver02、myserver03,部署在三台服务器上，集群Mycluster,代理Proxyserver,管理服务admin

在访问的高峰期还是慢卡，问题并没有所改善，代理是可以分发访问，测试中还发现一个情况，如果直接访问指定IP的三个服务节点，速度是正常的，但如果通过80端口的代理进行访问则还是慢卡，很奇怪，会不会是80端口的并发请求太大了，影响了处理的速度？？，但代理所在的服务器也没出现CPU、内存的高使用

2010-04-30 处理总结

第一阶段：例行性调整(单服务器、单服务节点)

ThreadPoolSize：500调整为250

JDBC连接池：100/200调整为200/200

表现：空闲期系统很正常，高峰期系统慢、卡，达到15-20秒，高峰期数据库压力大，活动会话数大，容易出现长时间会话，应用服务器的CPU和内存压力并不大

推断：内网100M网络的问题，高峰期产生阻塞，或者应用服务的HTTP处理能力不足问题

第二阶段：分拆应用服务(使用三台应用服务器，配置weblogic集群，一个管理服务，一个代理服务(应用前端)，两个服务节点(应用后端))

ThreadPoolSize：管理服务(30)，代理服务(80)，节点服务(80)

JDBC连接池：30/60

表现：

表现：问题依旧，空闲期系统很正常，高峰期系统慢、卡，达到15-20秒，高峰期数据库正常，活动会话数正常，未出现长时间会话，应用服务器的CPU和内存压力并不大

高峰期时候，访问通过代理访问是慢、卡，但直接访问节点服务则速度很正常。

推断：排除内网网络问题，可能是由于前端应用的处理能力不足影响的问题，

操作系统“开始->运行->cmd”，输入“netstat /s”，在“TCP Statistics for IPv4”信息中，“Current Connections”显示的就是访问连接的总数，正常情况一般是200—400，高峰会达到500—600

第三阶段：调整优化前端应用的处理能力

ThreadPoolSize：代理服务由80调整为450，

socket reader：33调整为66

accept bocking：50调整为200

Thread Priority：5调整为3(线程优先级，值越小优先级越高)

表现：系统高峰期访问正常

总结：

1.可以通过windows的netstat /s观察访问连接情况

2.ThreadPoolSize可以设置大一点，虽然还不清楚它占用的是什么资源CPU？？内存？？

如果代理服务的ThreadPoolSize设小的话，它也不会全部用完，设置越小它使用的越少，设置越大，它使用越大

weblogic控制台的监控曲线也受ThreadPoolSize的影响，ThreadPoolSize小了，控制台的监控曲线也会卡

3.可以考虑socket reader和accept bocking参数的调整

4.JDBC的连接数初始值不能设太大，太大了容易消耗数据库资源，对数据库产生压力

5.单节点服务和集群代理多节点服务的设置考虑要区别对待

其实大并发访问量对HTTP服务处理能力有更高的要求，一般建议通过硬件分发处理，如F5分发控制