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