最近测试环境的连接数老是不够用，session/process 都相应的从5000提到了8000，但还是不够，而且还是不断有新环境需要增加。最后根据评估，session数需要50000左右
根据粗略的计算来说,process也需要调整，按照如下的公式.
sessions=(1.1*process+5)
把semmns做了大幅度的调整,从32000调到了70000
> cat /proc/sys/kernel/sem
250 32000 100 256
> sysctl -a |grep sem
kernel.sem = 250 70000 100 256
第二天收到邮件说变更已经部上去了。说Process只调到了16000，当时看到邮件也没在意。
以下是监控的指标图，几分钟抓一个session报告。生成的图表如下。
开始两天，发现有了很大的改进，连接能够正常关闭，而且session数不到7000的样子。根据反馈没发现连接数的问题。
过了两天发现session数到8000以上就开始很吃力了。而且会时不时的有一些连接不上的情况。我写了个脚本，抓session快照的时候也有时候连不上库。
查看alert和listener日志，有以下的错误信息。
-->from Listener.log
03-DEC-2013 12:43:41 * (CONNECT_DATA=(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=testwrk34))(sid=TEST)) * (ADDRESS=(PROTOCOL=tcp)(HOST=172.19.192.41)(PORT=56631)) * establish * TEST * 12518
TNS-12518: TNS:listener could not hand off client connection
TNS-12536: TNS:operation would block
TNS-12560: TNS:protocol adapter error
TNS-00506: Operation would block
Linux Error: 11: Resource temporarily unavailable
-->from DB alert log
Errors in file /opt/app/oracle/aaa/admin/TEST/diag/rdbms/TEST/TEST/trace/TEST_psp0_30562.trc:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn5
Tue Dec 03 12:38:05 2013
在MOS上查看相关的信息，说是nproc的配置太低了，无法分配进程了。
但是查看nproc的情况,感觉没什么问题。
* soft nproc 32768
* hard nproc 65536
我就有些糊涂了。查看机器上其它的实例进程数，加起来都不到200个。
继续查看session的情况。最后反复验证，确认session数到8000的时候就开始有问题了。就开始琢磨nproc为什么没生效。
想到几天前的邮件，一查看，终于发现了端倪。
他们当时起库的时候，发现已经报了proc的错误，当调整process的时候，库直接起不来了。
SQL> startup
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semids_per_proc failed with status: 0
ORA-27301: OS failure message: Error 0
ORA-27302: failure occurred at: sskgpwcr2
ORA-27303: additional information: semids = 264, maxprocs = 45000
SQL> exit
起库的哥们已查看nproc的配置,db process设置为16000的时候库才能起来,然后他就直接设置为了16000,然后还有一些其他的问题，直接顺手解决了。
test2 @test1:/root > grep nproc /etc/security/limits.conf
# - nproc - max number of processes
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
* soft nproc 8192
* hard nproc 16384
SQL> startup
ORA-04031: unable to allocate 15193312 bytes of shared memory ("shared pool","unknown object","sga heap(3,0)","KEWS sesstat values")
SQL>
Tunning sga
*.sga_max_size= 6442450944 ==> 8442450944
*.sga_target=6442450944 ==> 8442450944
SQL> startup
ORACLE instance started.
Total System Global Area 8417955840 bytes
Fixed Size 2233168 bytes
Variable Size 3321892016 bytes
Database Buffers 5066719232 bytes
Redo Buffers 27111424 bytes
Database mounted.
Database opened.
查看邮件的情况，才发现nproc是在第二天早晨被unix team从8000调到16000的。问题的原因就找到了。
kernel的变更没有生效，只能稍候处理。
这个问题的定位确实有些曲折，希望在操作的时候保留日志之类的东西，这样诊断问题会有根据。
根据粗略的计算来说,process也需要调整，按照如下的公式.
sessions=(1.1*process+5)
把semmns做了大幅度的调整,从32000调到了70000
> cat /proc/sys/kernel/sem
250 32000 100 256
> sysctl -a |grep sem
kernel.sem = 250 70000 100 256
第二天收到邮件说变更已经部上去了。说Process只调到了16000，当时看到邮件也没在意。
以下是监控的指标图，几分钟抓一个session报告。生成的图表如下。
开始两天，发现有了很大的改进，连接能够正常关闭，而且session数不到7000的样子。根据反馈没发现连接数的问题。
过了两天发现session数到8000以上就开始很吃力了。而且会时不时的有一些连接不上的情况。我写了个脚本，抓session快照的时候也有时候连不上库。
查看alert和listener日志，有以下的错误信息。
-->from Listener.log
03-DEC-2013 12:43:41 * (CONNECT_DATA=(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=testwrk34))(sid=TEST)) * (ADDRESS=(PROTOCOL=tcp)(HOST=172.19.192.41)(PORT=56631)) * establish * TEST * 12518
TNS-12518: TNS:listener could not hand off client connection
TNS-12536: TNS:operation would block
TNS-12560: TNS:protocol adapter error
TNS-00506: Operation would block
Linux Error: 11: Resource temporarily unavailable
-->from DB alert log
Errors in file /opt/app/oracle/aaa/admin/TEST/diag/rdbms/TEST/TEST/trace/TEST_psp0_30562.trc:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn5
Tue Dec 03 12:38:05 2013
在MOS上查看相关的信息，说是nproc的配置太低了，无法分配进程了。
但是查看nproc的情况,感觉没什么问题。
* soft nproc 32768
* hard nproc 65536
我就有些糊涂了。查看机器上其它的实例进程数，加起来都不到200个。
继续查看session的情况。最后反复验证，确认session数到8000的时候就开始有问题了。就开始琢磨nproc为什么没生效。
想到几天前的邮件，一查看，终于发现了端倪。
他们当时起库的时候，发现已经报了proc的错误，当调整process的时候，库直接起不来了。
SQL> startup
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semids_per_proc failed with status: 0
ORA-27301: OS failure message: Error 0
ORA-27302: failure occurred at: sskgpwcr2
ORA-27303: additional information: semids = 264, maxprocs = 45000
SQL> exit
起库的哥们已查看nproc的配置,db process设置为16000的时候库才能起来,然后他就直接设置为了16000,然后还有一些其他的问题，直接顺手解决了。
test2 @test1:/root > grep nproc /etc/security/limits.conf
# - nproc - max number of processes
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
* soft nproc 8192
* hard nproc 16384
SQL> startup
ORA-04031: unable to allocate 15193312 bytes of shared memory ("shared pool","unknown object","sga heap(3,0)","KEWS sesstat values")
SQL>
Tunning sga
*.sga_max_size= 6442450944 ==> 8442450944
*.sga_target=6442450944 ==> 8442450944
SQL> startup
ORACLE instance started.
Total System Global Area 8417955840 bytes
Fixed Size 2233168 bytes
Variable Size 3321892016 bytes
Database Buffers 5066719232 bytes
Redo Buffers 27111424 bytes
Database mounted.
Database opened.
查看邮件的情况，才发现nproc是在第二天早晨被unix team从8000调到16000的。问题的原因就找到了。
kernel的变更没有生效，只能稍候处理。
这个问题的定位确实有些曲折，希望在操作的时候保留日志之类的东西，这样诊断问题会有根据。
