前段时间发布的系统(Oracle+weblogic)频繁挂掉,每天早上9点、下午2点高峰期就挂,纠结了很长时间,最终解决,方法描述下。
执行select count(*),status from v$session group by status;指令,发现不活动连接数比较大,当上升到一定数值之和,就挂。
做了下面优化,包括数据库的优化和WebLogic的优化。
1、数据库优化
1) 创建pfile SQL>create pfile from spfile
检查
- oracle/product/10.1.0/admin/orcl/pfile/init.ora.XXXXXXXX'(准确路径:/oracle/admin/ORADB/pfile/init.ora.352012231626)文件是否存在,备份到本地。
2) 停web服务,备份数据库,备份发布的代码
3) 查看参数并记录
1、show parameter sga
2、查看PGA_AGGREGATE_TARGET值
SELECT NAME, VALUE/1024/1024 MB
FROM v$pgastat
WHERE NAME IN ('aggregate PGA target parameter', 'global memory bound');
4) 修改pfile的内容
--alter system set sga_max_size=4096M scope=spfile ;
--alter system set sga_target= 4096M scope=spfile;
--alter system set pga_aggregate_target=2048M scope=spfile ;
alter system set pre_page_sga=true scope=spfile ;
alter system set lock_sga=true scope=spfile;
alter system set workarea_size_policy=auto scope=spfile ;
5) 修改limits.conf并重启电脑
/etc/security/limits.conf这个配置文件中添加如下的一行(oracle是启动数据库的操作系统账号),意思是oracle用户可以在物理内存中锁住任意大的空间:
oracle - memlock unlimited
然后重启操作系统reboot
6) 如果启动数据库失败,执行修复
startup pfile='……/product/10.1.0/admin/orcl/pfile/init.ora.XXXXXXXX'
7) 修改oracle连接池,并重启数据库
Oracle的sessions和processes的关系是
sessions=1.1*processes + 5
SQL>show parameter processes;
SQL>alter system set processes=1000 scope = spfile;
SQL>show parameter session;
SQL>alter system set sessions=1105 scope = spfile;
2、优化WebLogic
1) 修改web服务器连接池
weblogic所在服务器尚有26G内存,为满足1000并发访问量,可以将数据源连接池最高设置为2000。
初始容量改为500 当前设置值3
最大容量改为2000 当前设置值200
容量增长改为100 当前设置值3
重新启动weblogic
2) 修改web服务器JVM内存大小(参数待定)
找到安装目录下的weblogic\common\bin\commEnv.cmd文件
打开修改如下代码:
sun
if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode
set JAVA_VM=-client
set MEM_ARGS=-Xms1024mm-Xmx2048mm-XX:MaxPermSize=256m
set JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none goto continue :sun_prod_mode set JAVA_VM=-server ...
3) 发布新版程序
4) 重启web服务器操作系统
3、最终解决
经过上述处理,系统有明显优化,但是每天死机3次,早上8点,10点,下午3点左右。
经过执行下面2个指令,分别查看线程的活动情况和堆栈信息情况,可以跟踪到哪个方法导致系统堆栈延迟。
top -H 这个命令是查看是哪个线成比较忙
jstack -l 8032 | less 这个命令是查看堆栈信息,堆栈延迟中可以看到是执行了什么方法导致的。没有延迟就看不到,有延迟就能看到哪个方法导致系统堵塞,后来发现有个方法代码效率很低,而且访问最频繁,访问高峰时间正好和死机的时间吻合。
优化方法之后,系统稳定了。