HPUNIX调整文件打开数.docx
《HPUNIX调整文件打开数.docx》由会员分享，可在线阅读，更多相关《HPUNIX调整文件打开数.docx（9页珍藏版）》请在冰点文库上搜索。
HPUNIX调整文件打开数
一天，在一个业务高峰期，某省的一个数据库突然宕机了，根据alertlog中发现的报错：
MonJan1209:
49:
422009
ARC0:
Evaluatingarchive log5thread1sequence142032
ARC0:
Beginningtoarchivelog5thread1sequence142032
CreatingarchivedestinationLOG_ARCHIVE_DEST_1:
'/oraarchlog/arch_1_142032.arc'
MonJan1209:
49:
562009
ARC0:
Completedarchiving log5thread1sequence142032
MonJan1209:
57:
572009
Errorsinfile/oracle/app/oracle/admin/orasid/bdump/orasid_lgwr_8267.trc:
ORA-00313:
openfailedformembersofloggroup1ofthread1
ORA-00312:
onlinelog1thread1:
'/dev/vg_ora3/rredo_256m_21'
ORA-27041:
unabletoopenfile
HP-UXError:
23:
Filetableoverflow
Additionalinformation:
2
ORA-00312:
onlinelog1thread1:
'/dev/vg_ora2/rredo_256m_11'
ORA-27041:
unabletoopenfile
HP-UXError:
23:
Filetableoverflow
Additionalinformation:
2
ORA-00312:
onlinelog1thread1:
'/dev/vg_ora1/rredo_256m_01'
ORA-27041:
unabletoopenfile
HP-UXError:
23:
Filetableoverflow
Additionalinformation:
2
MonJan1209:
57:
572009
Errorsinfile/oracle/app/oracle/admin/orasid/bdump/orasid_lgwr_8267.trc:
ORA-00313:
openfailedformembersofloggroup1ofthread1
ORA-00312:
onlinelog1thread1:
'/dev/vg_ora3/rredo_256m_21'
ORA-27041:
unabletoopenfile
HP-UXError:
23:
Filetableoverflow
Additionalinformation:
2
ORA-00312:
onlinelog1thread1:
'/dev/vg_ora2/rredo_256m_11'
ORA-27041:
unabletoopenfile
HP-UXError:
23:
Filetableoverflow
Additionalinformation:
2
看来是打开文件数太多，导致了此次数据库宕机。
通过监控打开文件数发现，其实在前一天的时候，打开文件数已经到98%，在上午8点多的时候，打开文件数已经到99%，但是一直都没有引起监控人员的注意，终于导致打开文件数被撑爆。
我们通过sar-v可以发现打开文件数的总数：
HP-UXmy_db01B.11.11U9000/800 01/17/09
01:
08:
52text-sz ov proc-sz ov inod-sz ov file-sz ov
01:
08:
54 N/A N/A1139/4096 0 2678/348160 113494/2000100
01:
08:
56 N/A N/A1139/4096 0 2678/348160 113494/2000100
01:
08:
58 N/A N/A1135/4096 0 2675/348160 113487/2000100
01:
09:
00 N/A N/A1135/4096 0 2675/348160 113487/2000100
01:
09:
02 N/A N/A1135/4096 0 2675/348160 113487/2000100
其中的file-sz就是指打开文件数。
其中20多万的那个值是打开文件数的阈值，前者是当前实际打开的文件数。
这阈值是有核心参数nfile决定的。
我们在设置nfile的时候，建议是（15*NPROC+2048）；提醒值是oracle的process数乘以datafile数再加2048；极限值，在存数据库环境应该是os的极限进程数乘以数据文件数，即每个进程都打开所有的数据文件。
Nfile
MaxNumberofsimultaneouslyOpen
filessystem-wideatanygiventime.Total
numberofslotsitthefiledescriptortable,
default=16*（nproc+16+maxusers）/10+32+2*（npty+nstrpty）
recommended:
tousedefault.
>=Oracle9i=（15*NPROC+2048）
ForOracleinstallationswithahighnumberofdatafilesthismightbenotenough,thanusethe
>=（（numberoforacleprocesses）*（numberofOracledatafiles）+2048）
Nproc
MaxNumberofProcessesthatcanexist
simultaneouslyinthesystem,
default=（20+8*MAXUSERS）,
influencesninode,nfile.
recommended:
>=Oracle9i=4096
根据计算，如果根据建议值，那么nfile将设置成63488，如果根提醒值，将有141万，如果根据极限值，将有386万：
SQL> !
oracle@my_db01:
/oracle>kmtune|grepnproc
nproc 4096 - 4096
oracle@my_db01:
/oracle>exit
SQL>select15*4096+2048fromdual;
15*4096+2048
------------
63488
SQL>showparameterprocess
NAME TYPE VALUE
-----------------------------------------------------------------------------
processes integer 1500
SQL>
SQL>
SQL>selectcount（*）fromv$datafile;
COUNT（*）
----------
944
SQL>select1500*944+2048fromdual;
1500*944+2048
-------------
1418048
SQL>select4096*944fromdual;
4096*944
----------
3866624
SQL>
对于设置6万，肯定是完全不适合我们这个系统；如果设置141万或者设置386万，这似乎又太大了。
到底是什么进程需要打开那么多文件数？
在sar-v的命令中，我们只看到了一个总数，能具体的去看什么进程打开多少文件数吗？
在这里，HP提供了一个工具：
crashinfo。
可以查看各个进程的打开文件数：
crashinfo
用法是：
在root权限下：
my_db01#[/tmp]chmod+xcrashinfo
my_db01#[/tmp]./crashinfo-ofiles
此时能看到各个进程的打开文件数情况：
my_db01#[/tmp]./crashinfo-ofiles
crashinfo（4.74）
Note:
HPCONFIDENTIAL
libp4（9.305）:
Opening/stand/vmunix/dev/kmem
Loadingsymbolsfrom/stand/vmunix
KernelTEXTpagesnotrequestedincrashconf
Willuseanartificialmappingfroma.outTEXTpages
Commandline:
./crashinfo-ofiles
crashinfo（4.74）
pid p_maxofofilesp_comm
------------------------
1 4096 2 init
2011 4096 4 getty
94 4096 4 evmmirr
62 4096 4 emcpdaemon
63 4096 4 emcpProcd
64 4096 4 emcpd
65 4096 4 emcpdfd
66 4096 4 emcpwdd
67 4096 4 emcpstratd
68 4096 4 MpAsyncIoDaemo
69 4096 4 MpTestDaemon
70 4096 4 MpPirpNotDoneD
71 4096 4 MpPeriodicDaem
72 4096 4 MpDeferredDaem
73 4096 4 MpGeneralReque
74 4096 4 MpcAsyncIoDaem
75 4096 4 MpcResumeIoDae
76 4096 4 MpcPeriodicCal
129864096 671 oracle
130054096 671 oracle
132914096 10 oracle
129914096 671 oracle
……
224664096 51 oracle
123004096 847 oracle
128984096 9 oracle
123024096 979 oracle
130034096 671 oracle
130094096 670 oracle
130124096 459 oracle
130144096 49 oracle
Total=116775
my_db01#[/tmp]ps-ef|grep12298
oracle12298 1 0 Jan15 ?
9:
31ora_dbw0_orasid
root1246911867 102:
06:
39pts/te 0:
00grep12298
my_db01#[/tmp]ps-ef|grep12300
oracle12300 1 0 Jan15 ?
9:
32ora_dbw1_orasid
root1336311867 002:
16:
09pts/te 0:
00grep12300
my_db01#[/tmp]
通过ps-ef|grep打开文件数最多的几个进程号，发现打开文件数最多的进程是dbwr，smon，lgwr，chkpt。
每个进程基本上800～900个打开文件数，且dbwr进程有8个，打开文件数那就更加多了。
其他打开文件数较多的进程是LOCAL=NO的进程，通过观察spid关联sql_text，发现是对历史表的操作。
历史表是大表，表空间有300多个数据文件，因此，这些进程的打开文件数，也在每个600左右。
此时忽然记起，前段时间该省做优化时，当时DBA将dbwr进程数从2调整到了8，dbwr数增加了4倍，导致打开文件数也相应的增加，这应该就是造成nfile在近期慢慢增长到撑爆为止的原因了吧。
找到了原因，问题就比较好解决了。
找了一个停机的时间，把db_writer_processes调整回2，且为了以防万一，再将nfile值改为40万。
附：
crashinfo命令的其他用法：
Usage:
crashinfo[options...][coredir|kernelcore]
Default:
coredir="."if"INDEX"filepresentelse
kernel="/stand/vmunix"core="/dev/kmem"
Options:
-h|-help[flag,flag...]
flags:
detail
-u|-update
-v|-verbose
-c|-continue
-H|-Html
-e|-email[,flag,flag...]
flags:
file=
from=
callid=
-t|-trace[flag,flag...]
flags:
args
regs （PAOnly）
Rregs （PAOnly）
locals （IA64Only）
frame （IA64Only）
mems （IA64Only）
bsp （IA64Only）
ss （IA64Only）
-s|-syscall
-f|-full_comm
-S|-Sleep
-l|-listonly[flag,flag...]
flags:
pid=
-top[count]
-p|-proctree[flag,flag...]
flags:
tids
-i|-ioscan
-ofiles[pid][,flag,flag...]
flags:
tids
-signals[pid]
-seminfo
-unlinked[all]
-m|-msginfo[flag,flag...]
flags:
skip
id=
msg=
type=
-flocks[flag,flag...]
flags:
sleep
vnode=
inode=
-sgfr[version]
-fwlog[cpu]
-vmtrace[flag,flag...]
flags:
bucket=
arena=
count=
leak
cor
log
parse
如：
my_db01#[/tmp]ps-ef|grepckpt
oracle12304 1 0 Jan15 ?
3:
29ora_ckpt_orasid
root1350911867 002:
18:
35pts/te 0:
00grepckpt
my_db01#[/tmp]
my_db01#[/tmp]./crashinfo-ofiles12304
crashinfo（4.74）
Note:
HPCONFIDENTIAL
libp4（9.305）:
Opening/stand/vmunix/dev/kmem
Loadingsymbolsfrom/stand/vmunix
KernelTEXTpagesnotrequestedincrashconf
Willuseanartificialmappingfroma.outTEXTpages
Commandline:
./crashinfo-ofiles12304
crashinfo（4.74）
pid p_maxofofilesp_comm
------------------------
123044096 961 oracle
my_db01#[/tmp]
·【文章发布信息】发表于：
2009-01-17@02:
22:
05·||分类：
..experience,Workingcase
·【分享或收藏】：
5条评论»
1.David.Guo于2009-01-17@19:
15:
27留言：
nfile的使用要监控起来，我们这边一般到85就开始要走应急流程处理了。
85，是生命线呀
2.小荷于2009-01-17@23:
40:
53留言：
reDavid.Guo：
我们也是有监控的，不过没引起监控人员的注意。
唉，失败呀～～～
不过更失败的是SA的serviceguard没配好，没monitor到oracle进程，数据库宕机后竟然没自动切换到B机。
3.dhhb于2009-01-19@12:
50:
56留言：
我们这里nfile是100W.呵呵
我记得lsof可以看打开文件数的。
4.oracle.dba于2009-02-25@21:
51:
17留言：
最近也遇到这个问题了，但是没有工具进行分析查看。
能否把这个crashinfo的工具共享下，网站上下载不下来，
发我邮箱也可以
ora315@
谢谢！
5.make于2009-05-14@17:
06:
27留言：
我也遇到这个问题，按照metalink的提示增加了
nproc=MaxNumberofProcesses
nfile=MaxNumberofOpenFiles
nflocks=MaxNumberofFileLocks
的值，但是file-sz的值一直在涨（要是股票就好了），最后又down了，再增大，再dwon，我晕了。
请何大师指点
升级会员 