最近公司系统由原来小机迁移到IDC机房,应用在虚拟机环境下运行,出现了性能问题,表现为用户上来之后系统承受不住压力而宕机,打不开界面。
经过一周的各种尝试,最终得以解决,记录一下以免下次犯同样的错误,一周时间这个代价是非常大的。
经过就不多说了,直接说需要做什么就OK.
1.首先需要测试服务环境,CPU,网络、IO,内存,存储空间,可使用工具进行各项测试,本次我采用FTP上传下载大文件(2G)来进行实际测试。
2. 数据库IO测试,
3.数据库连接数,即:SESSION ,PROCESS参数设定。
1).sessions
Sessions 参数指定了一个 Instance中能够同时存在的sessions数量,或者说,就是能同时登陆到数据库的并发用户数。通常,我们设定这个数字时需要考虑我们可能会有多少个同时连接到数据库的并发用户,并加上后台进程的进程数,最后乘与1.1.
比如说,估计系统中可能会同时有100个用户连接到数据库,那么,你的session最少应该为
(100 + 10 ) * 1.1 = 121
当数据库连接的并发用户已经达到这个值时,又有新session连进来,就会报错
00018, 00000, "maximum number of sessions exceeded"
// *Cause: All session state objects are in use.
// *Action: Increase the value of the SESSIONS initialization parameter.
2). Processes
Processes参数指定了Instance在OS层面所能同时运行的进程数。基于和sessions设定同样的考虑,我们在设定processes时,也应考虑我们可能会有多少个同时连接到数据库的并发用户,并加上后台进程的进程数。
当然,在MTS(shared server)的配置下,这个值的确定会有所不同。应该是普通后台进程+最大共享服务器的进程数(max_shared_servers) + 最大Dispatcher进程数(max_dispatchers).
另外,由于在window平台中,Oracle是以单一一个进程的形式存在,Processes 参数变成了限制Oracle进程里的线程数了。
当Oracle需要启动新的process而又已经达到processes参数时,就会报错:
00020, 00000, "maximum number of processes (%s) exceeded"
// *Cause: All process state objects are in use.
// *Action: Increase the value of the PROCESSES initialization parameter.
3).通过SQLPlus修改
使用sys,以sysdba权限登录:
SQL> show parameter processes;
NAME TYPE VALUE
------------------------------------ ----------- ---------------------------------------
aq_tm_processes integer 1
db_writer_processes integer 1
job_queue_processes integer 10
log_archive_max_processes integer 1
processes integer 150
SQL> alter system set processes=2000 scope = spfile;
系统已更改。
SQL> show parameter processes;
NAME TYPE VALUE
------------------------------------ ----------- -----------------------------------------
aq_tm_processes integer 1
db_writer_processes integer 1
job_queue_processes integer 10
log_archive_max_processes integer 1
processes integer 2000
SQL> create pfile from spfile;
文件已创建。
4.调整weblogic JDK ,使用1.6 64bit,设置weblogic 内存大小
5.调整weblogic 线程数
6.搭建weblogic 集群,充分利用机器CPU,内存性能。
7.创建weblogic 连接池,这里环境为:weblogic 10.3.6,oracle 10,所以不能采用GridLink 方式,
方式 1):
在WEBLOGIC上配置了一个多池,利用WEBLOGIC提供的负载均衡策略,将并发均衡的分别到两个节点上。
方式 2):
直接使用了RAC的负载均衡策略。
配置数据源时,URL修改为如下
jdbc:oracle:thin:@(description=(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = 10.11.1.159)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = 10.11.1.158)(PORT = 1521))(load_balance=yes)(failover=yes))(connect_data=(service_name= racdb)(instance_name=racdb1)(instance_name=racdb2)))
方式 3):
oracle 11g 以后支持GrildLink 后续详细学习( http://blog.sina.com.cn/s/blog_48567d850102v3rj.html?qq-pf-to=pcqq.c2c )
测试结果,方式1 压力全部集中在一个节点上。方式2 负载均衡的实现还是比较好的,基本上两个节点的负载差别很小。
要想在任何情况下都获得比较理想的负载均衡,最好使用Oracle的负载均衡策略,而不要使用WEBLOGIC的多池提供的LOAD-BALANCING策略
附通过数据库查看各节点连接情况:
SQL> SELECT INST_ID, STATUS, COUNT(*)
2 FROM GV$SESSION
3 WHERE USERNAME = 'NDMAIN'
4 GROUP BY INST_ID, STATUS;
INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 8
1 ACTIVE 1
2 ACTIVE 2
2 INACTIVE 7
同样可以在weblogic 控制台的监控中直观的看到服务器各节点JDBC的负载和活动情况。
8.测试负责均衡会话共享。
9 压力测试并发访问,需要达到15分钟以上稳定运行。