新华人寿渠道管理系统性能测试报告.docx

新华人寿渠道管理系统性能测试报告2010年5月21日 新华人寿银代渠道销售管理系统性能测试报告 文档信息文档标题新华人寿渠道管理系统性能测试报告版 本 号v1.1版本日期2010-5-14打印日期文 件 名新华人寿渠道管理系统性能测试报告归档目录管理人员审批信息姓名部门/角色意见日期修改历史版本日期修改说明修改人1.02010-5-14草稿1.12010-5-20初稿目录1.概述51.1项目背景51.2测试目的52.测试范围62.1测试目标62.2业务模型63.测试环境83.1系统架构图83.2测试环境机器配置表84.测试方法94.1基准测试94.2单交易负载测试94.3混合场景负载测试93.4性能测试案例设计103.4.1系统登录103.4.2人员信息查询103.4.3销售团队查询113.4.4网点信息查询113.4.5人员基本信息维护123.4.6销售团队信息维护123.4.7网点基本信息维护一三3.5性能测试场景设计一三3.5.1系统登录一三3.5.2人员信息查询143.5.3销售团队查询143.5.4网点信息查询143.5.5人员基本信息维护143.5.6销售团队信息维护一五3.5.7网点基本信息维护一五3.5.8混合场景负载测试一五5.测试计划176.测试结果一八6.1基准测试一八6.1.1系统登录一八6.1.2人员查询一八6.1.3团队查询一八6.1.4网点查询196.1.5人员维护196.1.6团队维护196.1.7网点维护196.2单交易负载测试196.2.1系统登录196.2.2人员查询266.2.3 团队查询316.2.4 网点查询326.2.5 人员维护336.2.6 团队维护336.2.7 网点维护346.3混合场景负载测试396.4其他负载测试416.4测试结论与建议42结论42建议437.附件1：451. 概述1.1项目背景本系统的目标是使渠道业务日常管理电子化、简单化，对各渠道业务发展提供强大的后台数据支持。现阶段公司迅速发展，业务迅速扩张，业务拓展模式不断创新。公司的销售渠道涉及到个人营销保险、团体保险、银行保险、至尊理财、电话营销保险等多个领域，由于各个领域的保险特点不同、管理方法也呈现出多样性。需要的是一套能够处理并突出体现各个保险领域的特性的销售管理系统，从管理角度出发对销售的各个阶段进行控制，对销售人员进行管理，为销售人员提供从培训、售前、售后以及佣金结算等一系列完整的服务支持。为达到这一目标，需要利用现代的信息处理技术和科学手段，全面实现销售管理中的各项要求，通过计算机辅助实现管理的科学化、规范化、系统化与自动化，与业务系统一起建立一套完整的保险管理系统和网络。1.2测试目的通过模拟，在测试环境上尽量真实再现新华人寿银代渠道销售管理系统生产环境的日常业务量高峰时的场景。通过结果分析，查看哪些业务出现响应时间长，交易失败的情况。查看新华人寿银代渠道销售管理系统是否符合设计的性能要求。2. 测试范围2.1测试目标性能测试是针对系统并发处理能力、交易响应时间等性能指标所进行的测试。目的是在尽可能模拟生产环境的前提下，单一渠道方面的性能，实现以下目标（相关指标参考合同附件）：Ø 模拟系统在实际生产环境下峰值时的系统处理能力及性能表现。Ø 检测软件中的问题：通过并发测试执行，揭示程序中的隐含的问题或冲突，从而修复系统中的薄弱环节。Ø 通过对各项测试及监控结果的综合分析，发现、定位性能瓶颈，为改善系统性能提供整体优化方案，为后期性能调优提供参考依据。Ø 保证在生产环境的业务和用户量下，性能满足业务人员操作需求，主要需求如下：l 日常平均在线用户数500人，高峰期在线用户数700人。 注：目前核心业务系统有效用户数：24045，核心业务系统日常在线用户数平均为2.6K ，高峰期在线用户数为3.6K，渠道系统按照核心系统用户数量的20%计算，所以平均在线用户数量为500，高峰为700。l 薪资考核计算效率：ü 考核计算、薪资计算均能够在2-4小时内完成。l 其他操作时效要求如下：ü 提交信息维护，系统应在2秒内响应。ü 按照机构号或人员编码查询信息详情，系统应在2秒内响应。ü 按照条件查询清单，系统应在一五-30秒内响应。ü 按照条件生成统计报表，根据复杂性，系统响应时间不同，最慢应在5分钟内响应。ü 按分支机构进行考核确认，系统应在一五分钟内完成。2.2业务模型序号业务模块业务名称类型数据量平均用户数最大用户数响应时间1系统登录系统登录登录5007005秒2人员管理人员查询查询4000050070030秒3网点管理网点信息查询查询300050070030秒4团队管理销售团队查询查询300050070030秒5人员管理人员修改交易5007005秒6网点管理网点修改交易5007005秒7团队管理团队修改交易5007005秒8薪资考核普处理批处理管理批处理5006002-4小时注：业务模型选择参考了运维部门提供的菜单使用频率参考此处需要对性能场景设计，先做个简单说明。30并发的测试场景，以登录为例，每个并发用户，迭代登录20次，也就是说30并发，在1.5分钟内前后共有30*20=600人次登录系统， 40并发场景，在2分钟内有40*20=800人次登录，50并发场景，在2.5分钟内有50*20=1000人次登录。3. 测试环境3.1系统架构图3.2测试环境机器配置表系统服务器配置操作系统及安装软件台数应用服务器应用服务器服务器:1*2.6G双核2G 内存 320G 硬盘 1电源Red hat nash 5.1.19.6JDK1.6.0JBoss 41销售管理平台数据库和元数据数据库数据库服务器服务器:1*2.6G双核4G 内存 320G 硬盘 1电源Red hat nash 5.1.19.6Oracle 10g 14. 测试方法4.1基准测试测试环境确认之后，对业务模型中涉及的每种业务（系统登录、人员查询、团队查询、网点查询、人员维护、网点维护、团队维护）做基准测试。目的是检查业务本身是否存在性能缺陷。同时为将来的混合场景负载测试性能分析提供参考依据。场景设置：编写测试客户端向新华人寿银代渠道销售管理系统应用服务器发送业务请求并接收返回结果的脚本，在系统无压力情况下运行10次迭代，每次迭代间等待1秒，取业务的平均响应时间作为衡量指标。4.2单交易负载测试单交易负载测试是对业务模型中涉及的每种业务（系统登录、人员查询、团队查询、网点查询、人员维护、网点维护、团队维护）加上一定量的负载，进行测试以获取该交易的性能指标。目的是为了验证这些典型交易是否存在并发问题，并获取其响应时间，作为混合场景测试中业务模型配比的参考。场景设置：制作单个交易的性能测试脚本，在负载测试工具中设置并发用户数等于30、40、50，每秒登陆10个用户，迭代20次，每次迭代等待1秒，忽略思考时间，获取平均响应时间。30并发=600人次，40并发=800人次，50人次=1000人次。4.3混合场景负载测试混合场景负载测试是按照业务模型的约定，在一定量的并发情况下测试以下指标：业务的平均交易响应时间、应用服务器、数据库服务器的资源使用情况、交易正确率等。通过性能测试，可以模拟实际生产环境中在业务处理高峰期实物资产管理系统的压力情况，得到此时的实物资产管理系统性能表现数据，为系统的实际上线运行提供可靠的参考。场景设置：按照业务模型比例设置测试场景，设置并发量60，每1秒登陆10个用户，忽略思考时间，每次运行测试一五分钟，每次迭代间等待1秒，收集系统性能变化曲线。 4.4性能测试案例设计4.4.1系统登录系统登录脚本名称系统登录程序版本用例编号XH-XTDL-01子系统测试目的测试用户登录的并发能力及系统响应时间。特殊说明目标产生大压力，忽略全部思考时间。前提条件应用程序已经部署，同时存在不同身份的系统使用用户步骤操作是否设置集合点是否设定事务事务名称说明1打开登录页否否2输入用户名、密码、选择机构否否3点击“登录”按钮是是登录设置检查点4登陆后展现页面信息否否5注销用户否是注销编制人员编制日期2010-04-一三4.4.2人员信息查询人员信息查询脚本名称人员查询程序版本用例编号XH-RYCX-02子系统测试目的测试人员信息查询功能系统响应时间。特殊说明目标产生大压力，忽略全部思考时间。前提条件应用程序已经部署 步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2选择人员管理à人员信息管理à人员信息查询否是进入人员查询菜单3输入查询条件否是录入人员查询条件4点击“查询”按钮否是人员查询5勾选需要查询的人员记录，点击明细按钮否是人员明细设置检查点编制人员编制日期2010-04-一三4.4.3销售团队查询销售团队查询明细脚本名称销售团队查询程序版本用例编号XH-TDCX-03子系统测试目的测试销售团队查询功能的系统响应时间。特殊说明目标产生大压力，忽略全部思考时间。前提条件应用程序已经部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2选择销售团队管理à销售团队查询明细否是进入团队查询菜单3点选查询条件 否是录入团队查询条件4点击“查询”按钮否是团队查询5勾选需要记录，点击销售团队明细按钮否是团队明细设置检查点编制人员编制日期2010-04-一三4.4.4网点信息查询网点基本信息查询脚本名称网点信息查询程序版本用例编号XH-WDMX-04子系统测试目的测试网点基本信息维护系统响应时间。特殊说明目标产生大压力，忽略全部思考时间。前提条件应用程序已经部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单：银保渠道à网点管理à网点信息维护否是进入网点查询菜单3输入查询条件否是录入网点查询条件4点击“查询”按钮否是网点查询5点击“明细”按钮否是网点明细编制人员编制日期2010-04-一三4.4.5人员基本信息维护人员基本信息维护脚本名称人员入司程序版本用例编号XH-RYRS-05子系统测试目的测试人员入司的系统响应时间。特殊说明目标产生大压力，忽略全部思考时间。前提条件应用程序已经部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单：银保渠道à人员管理à人员信息管理à人员信息维护否是进入人员新增菜单3点击新增按钮否是进入人员修改界面设置检查点4录入或者选录人员信息否是人员信息录入5点击“新增”按钮否是人员入司编制人员编制日期2010-04-一三4.4.6销售团队信息维护销售团队信息维护脚本名称团队新增程序版本用例编号XH-TDXZ-06子系统测试目的测试团队新增的系统响应时间。特殊说明目标产生大压力，忽略全部思考时间。前提条件应用程序已经部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单：银保渠道à销售团队管理à销售团队维护否是进入团队维护菜单3点击新增按钮否是进入团队新增界面4录入或者选录团队信息团队信息录入5点击“新增”按钮否是团队新增编制人员编制日期2010-04-一三4.4.7网点基本信息维护网点基本信息维护脚本名称网点新增程序版本用例编号XH-WDWH-07子系统测试目的测试网点基本信息维护系统响应时间。特殊说明目标产生大压力，忽略全部思考时间。前提条件应用程序已经部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单：网点管理à网点信息维护否是进入网点维护菜单3点击新增按钮否是进入网点新增界面设置检查点4填选网点信息否是填写网点信息5点击新增按钮否是网点新增编制人员编制日期2010-04-一三4.4.8 薪资考核批处理网点基本信息维护脚本名称薪酬计算程序版本用例编号XH-XZKH-20子系统测试目的测试薪资考核系统响应时间。特殊说明通过前台操作，对系统造成负载压力前提条件应用程序已经部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单：银保渠道à批处理管理à薪酬计算申请否是进入薪酬计算菜单3选择部门、月份否是选择薪酬计算条件4点击申请按钮否是薪酬计算申请编制人员编制日期2010-05-244.5性能测试场景设计4.5.1系统登录序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1系统登录基准测试系统登录110001002系统登录30并发系统登录302001011003系统登录40并发系统登录402001011004系统登录50并发系统登录502001011004.5.2人员信息查询序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1人员查询基准测试人员查询110001002人员查询30并发人员查询302001011003人员查询40并发人员查询402001011004人员查询50并发人员查询502001011004.5.3销售团队查询序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1团队查询基准测试团队查询110001002团队查询30并发团队查询302001011003团队查询40并发团队查询402001011004团队查询50并发团队查询502001011004.5.4网点信息查询序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1网点查询基准测试网点查询110001002网点查询30并发网点查询302001011003网点查询40并发网点查询402001011004网点查询50并发网点查询502001011004.5.5人员基本信息维护序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1人员入司基准测试人员入司110001002人员入司30并发人员入司302001011003人员入司40并发人员入司402001011004人员入司50并发人员入司502001011004.5.6销售团队信息维护序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1团队新增基准测试团队新增110001002团队新增30并发团队新增302001011003团队新增40并发团队新增402001011004团队新增50并发团队新增502001011004.5.7网点基本信息维护序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1网点新增基准测试网点新增110001002网点新增30并发网点新增302001011003网点新增40并发网点新增402001011004网点新增50并发网点新增502001011004.5.8薪资考核计算测试序号场景名称场景说明执行脚本用户总数循环数量操作间隔查询时间一次查询二次查询三次查询四次查询1薪资考核基准测试薪资考核110510一五202薪资考核30并发计算薪资考核301030601202403薪资考核40并发计算薪资考核401030601202404薪资考核50并发计算薪资考核50103060120240注：薪酬计算场景比较特殊，计算完成时没有在前台提示，所以才用roadrunner前台提交计算申请，记录开始时间；通过去数据库查询或者在前台界面查询计算结果 ，直到查询出需要的所有结果，记录时间。结束时间-开始时间约为薪资考核计算所用时间。所有计算应该在4小时之内完成计算。4.5.9混合场景负载测试由于压力演示环境并发用户适量限制，混合场景设置为60人并发混合场景，主要是测试使用频率最高查询功能。序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1系统登录60并发系统登录0运行一五分钟01150人员查询人员查询30团队查询团队查询20网点查询网点查询10人员修改人员修改0网点修改网点修改0团队修改团队修改0薪酬计算薪酬计算前台提交计算申请，后台一直运行注：薪酬计算场景比较特殊，计算完成时没有在前台提示，所以才用roadrunner前台提交计算申请，后台一直运行计算，作为负载。5. 测试计划内容开始日期结束日期人力资源金涛李勇君王利鹏测试环境和版本确认2010-4-122010-4-12üü测试方案编写与评审2010-4-一三2010-4-16üü测试数据准备2010-5-072010-5-10üü测试脚本开发2010-5-102010-5-11üü测试场景设置2010-5-122010-5-一三üü测试执行2010-5-122010-5-一三üü测试结果分析2010-5-142010-5-14üüü测试报告编写2010-5-142010-5-14üüü系统调优后测试2010-5-172010-5-20ü修改测试报告2010-5-202010-5-21ü报告评审2010-5-242010-5-256. 测试结果6.1基准测试6.1.1系统登录6.1.2人员查询6.1.3团队查询平均响应时间6.1.4网点查询 6.1.5人员维护 待测6.1.6团队维护 待测6.1.7网点维护 6.2单交易负载测试6.2.1系统登录平均响应时间（单位：秒）30人并发：40人并发：50人并发响应时间分析：基准响应时间为：0.675s，在单交易负载测试环境下，30并发系统响应时间为3.386s，40并发系统响应时间为4.82s；50并发用户系统响应时间为6.002s。30并发、40并发，响应时间小于5秒，符合测试目标；50登录响应时间大于测试目标要求时间。CPU利用率（单位：百分比）30人并发：40人并发：50人并发CPU利用率分析：在负载测试过程中，随着压力的增大，应用服务器使用：30并发情况下，应用服务器cpu使用率为峰值80%，平均使用率77%，在正常范围之内；40并发情况下，应用服务器cpu使用率为峰值100%，平均使用率81%，处以满负荷运行；50并发情况下，应用服务器cpu使用率为峰值89%，平均使用率78% ，处以满负荷运行；数据库服务器cpu使用率，峰值均未超过50%，平均值均为超过 35%，使用正常；内存应用服务器物理内存使用情况如图，物理内存容量为2G，空闲约为50M。数据库服务器物理内存使用情况如图，物理内存容量为4G，运行负载时空闲最大约为500M，最小为0；吞吐量（单位：字节/秒）：30人并发：40人并发50人并发吞吐量分析：30人并发吞吐量平均约为9.2M/S, 峰值约为14.5M/S,；40人并发吞吐量平均约为9.7M/S,峰值约为16.5M/S,50人并发吞吐量平均约为8.8M/S,峰值约为17 M/S,由此可见3040并发之间，随着用户并发数增加平均吞吐量呈上升趋势，4050并发并发用户数量增加了，平均吞吐量反而有所减小，由于并发用户超过系统响应能力，所以系统在现有环境下的处理能力约为9.5M/S。处理事务数量(单位：个/ 秒)30并发40并发：50并发:处理事务数量分析：30并发处理事务量 6.3个/秒，40并发处理事务量10.4个/秒，50并发处理事务量6个/秒，由此可见，40并发系统处理能力最高。6.2.2人员查询平均响应时间（单位：秒）30人并发：40人并发：50人并发响应时间分析：基准响应时间为：0.286s，在单交易负载测试环境下，30并发系统响应时间为5.086s，40并发系统响应时间为6.371s；50并发用户系统响应时间为8.一三3s。系统在一五-30秒之内返回结果，完成测试目标要求。CPU利用率（单位：百分比）30人并发：40人并发：50人并发CPU利用率分析：在负载测试过程中，随着压力的增大，应用服务器的CPU成为系统瓶颈。30并发情况下，应用服务器cpu使用率为峰值99%，平均使用率84%，处以满负荷运行；40并发情况下，应用服务器cpu使用率为峰值99%，平均使用率86% ，处以满负荷运行；50并发情况下，应用服务器cpu使用率为峰值99%，平均使用率85%，处以满负荷运行；数据库服务器cpu使用率，峰值均未超过60%，平均值均约为超过 35%，使用正常；吞吐量（单位：字节/秒）：30人并发：40人并发50人并发吞吐量分析：30人并发吞吐量平均约为7.5M/S, 峰值约为10M/S,；40人并发吞吐量平均约为7.7M/S,峰值约为14.5M/S,50人并发吞吐量平均约为7.7M/S,峰值约为10M/S,由此可见系统在现有环境下，处理能力约为7.6M/S。处理事务数量(单位：个/ 秒)30并发40并发：50并发:6.2.3 团队查询平均响应时间（单位：秒）30人并发：40人并发：50人并发响应时间分析：基准响应时间为：0.1一八s，在单交易负载测试环境下，30并发系统响应时间为1.355s，40并发系统响应时间为1.681s；50并发用户系统响应时间为2.101s。系统在一五-30秒之内返回结果，完成测试目标要求。团队查询其他参数结果类似于人员查询。6.2.4 网点查询平均响应时间（单位：秒）30人并发：40人并发：50人并发响应时间分析：基准响应时间为：0.19s，在单交易负载测试环境下，30并发系统响应时间为2.988s，40并发系统响应时间为3.509s；50并发用户系统响应时间为4.832s。系统在一五-30秒之内返回结果，完成测试目标要求。网点查询其他参数结果类似于人员查询。6.2.5 人员维护待测6.2.6 团队维护待测6.2.7 网点维护平均响应时间（单位：秒）30人并发：40人并发：50人并发响应时间分析：基准响应时间为：0.208s，在单交易负载测试环境下，30并发系统响应时间为0.594s，40并发系统响应时间为1.5s；50并发用户系统响应时间为1.35s。网点新增系统响应时间小于5秒，符合测试目标。CPU利用率（单位：百分比）30人并发：40人并发：50人并发吞吐量（单位：字节/秒）：30人并发：40人并发50人并发吞吐量分析：30人并发吞吐量平均约为7.5M/S, 峰值约为12.5M/S,；40人并发吞吐量平均约为8.5M/S,峰值约为一三M/S,50人并发吞吐量平均约为7M/S,峰值约为10M/S,由此可见3040并发之间，随着用户并发数增加，吞吐量呈上升趋势，4050并发并发用户数量增加了，吞吐量反而有所减小。 处理事务数量(单位：个/ 秒)30并发40并发：50并发:6.3混合场景负载测试平均响应时间（单位：秒）：CPU利用率吞吐量（单位：字节/秒）：混合场景结果：混合查询场景60用户并发，人员查询响应时间为：4.069s，网点查询响应时间为：3.672s，团队查询响应时间为：3.266s，系统在一五-30秒之内查询出结果，完成测试目标要求。应用服务器cpu峰值使用率为99%，平均使用率为88%，满负载工作；数据库服务器cpu峰值使用率为70%，平均使用率为20%，工作在正常范围；6.4其他负载测试测试场景设置如下：序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1系统登录100并发系统登录0运行一五分钟01150人员查询人员查询40团队查询团队查询30网点查询网点查询30人员修改人员修改0网点修改网点修改0团队修改团队修改0响应时间如下：系统后台报异常，错误日志如下图。需要对系统进行调优。6.4测试结论与建议结论在目前测试环境下（以混合场查询景为例）。应用服务器cpu和物理内存容量成为系统瓶颈。对系统施加压力时，cpu queue length（排队进程）队列平均长度在510，使用率达到80%以上，现有双核cpu不能及时处理并发请求，形成系统瓶颈，需要升级。内存方面，物理内存空闲约50M，若要并发处理更多用户，需要升级。数据库服务器物理内存成为系统瓶颈。数据库受内存制约，物理内存剩余80M，形成系统瓶颈，需要升级。Cpu使用率峰值未超过55%，平均使用率在50%，进程有排队现象（Queue Lenght），若需要处理更大数量的并发，建议增加cpu数量，增强并发处理能力。综上，应用服务器和数据库服务器，对系统性能都有所制约。建议根据本次性能测试结果，对系统提出以下改进性能的建议：l 对于测试环境：1 建议对现有硬件经行升级。参考配置见 附件1；2 现有服务器部署于百兆局域网内，100M带宽的实际传输速度为于12M左右，本次测试使用10M，如果需要处理更大量的并发请求，服务器需要部署在千兆网内，服务器网卡使用100/1000M网卡。3 应用服务器压力较大，若使用范围是是全国范围，建议考虑负载均衡；l 对于程序：1 100用户并发查询，jboss后台报异常日志，需要优化应用服务器打开文件数。详见：6.4其他负载测试2 需要优化程序war包数据连接数；3 需要优化数据库连接数，以oracle为例需要调整processes和sessions；4 需要对数据库查询优化名称30并发40并发响50并发60并发混合人员查询5.0866.3718.一三34.069（50%）团队查询1.3551.6812.1013.672（33%）网点查询2.9883.5094.8323.266（17%）由此可见，对数据量较大、关联较多的人员查询，系统响应时间相对较长。需要进行数据库查询优化。建议对现在系统中，用户UI中查询条件做为必选项的条件建立索引。本次测试对系统设置做了以下调整，供参考。1 程序war包数据连接调整Ø 找到war所在路径双击打开; 以10.1.110.237为例：/jboss/JBoss-4.2.2.GA/server/default/deploy/ CSMP_XINHUA.war Ø 用文本编辑器打开配置文件: WEB-INFclassesapplicationContext.xml Ø 找到以下节点<property name="initialPoolSize" value="1" />   <property name="minPoolSize" value="10" />   <property name="maxPoolSize" value="50" /> Ø 修改value值完成war包连接池修改initialPoolSize ：初始连接minPoolSize：最小连接maxPoolSize：最大连接value修改原则：maxPoolSize不得大于oracle连接的sessions；最小连接，初始连接不得的大于最大连接。2 oracle数据库连接调整操作方法：Ø 登录Linux客户端 Ø 以数据库管理员身份登录sqlplus Ø 使用如下命令查看processes和sessionsshow parameter processes show parameter sessions Ø 使用如下命令修改processes和sessions alter system set processes=300 scope=spfile;alter system set sessions=335 scope=spfile; Ø processes和sessions数量应该满足：sessions=(1.1*process+5) 3 Oracle数据库磁盘空间已满，增加表空间数据文件Ø 磁盘分区：fdisk /dev/sdaMkdisk t ext3 /dev/sda6Mkdir oracledataMount t ext3 /dev/sda/ /oracledata/Ø 数据库操作：登录以数据库管理员身份登录sqlplus;Alter tablespace user add datafile /oracledata/user02.dbf size 6G autoextend on next 100M maxsize unlinted;4 修改Linux系统最大打开文件数（应用服务器）打开linux终端，使用root登录查看：ulimit a 修改：ulimit n 80967. 附件1：建议升级配置1.2.202316:4716:47:3523.1.24时47分4时