解决Oracle+weblogic系统死机的问题

时间:2022-02-23 08:43:13

前段时间发布的系统(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  这个命令是查看堆栈信息,堆栈延迟中可以看到是执行了什么方法导致的。没有延迟就看不到,有延迟就能看到哪个方法导致系统堵塞,后来发现有个方法代码效率很低,而且访问最频繁,访问高峰时间正好和死机的时间吻合。

优化方法之后,系统稳定了。