一次HP小型机当要几处理全过程
HP rx3600小机已经出现4次无故当机(磁盘资源被不正常的进程占用完，导致系统及应用软件都无法正常的使用)的情况。首先硬件经过hp工程师确认是没问题的。都是正常运行状态。问题出在软件方面，之前一直认为是HP系统或者是Service Guard的问题，但通过hp工程师确认hp的软件也是正常的之后，开始把重点放到了Oracle身上，终于找到了一些切入口来分析。
2 问题分析及处理1. hp工程师确定了hp硬件、软件都没有异常。
2. 开始着手着重从oracle方面查找原因(这是我的问题，之前意识上将问题强加于hp)。
处理步骤：
Ø 认真查看告警日志：alter_dlyx.log
发现了如下异常：
Errors in file /oracle/admin/dlyx/bdump/dlyx_cjq0_16372.trc:
Wed Jun 30 18:41:00 EAT 2010
Process q001 died, see its trace file
Wed Jun 30 18:41:08 EAT 2010
ksvcreate: Process(q001) creation failed
Wed Jun 30 18:44:34 EAT 2010
Process J000 died, see its trace file
Wed Jun 30 18:44:37 EAT 2010
kkjcre1p: unable to spawn jobq slave process
Wed Jun 30 18:44:40 EAT 2010
Errors in file /oracle/admin/dlyx/bdump/dlyx_cjq0_16372.trc:
Wed Jun 30 18:47:29 EAT 2010
Process m000 died, see its trace file
Wed Jun 30 18:47:32 EAT 2010
ksvcreate: Process(m000) creation failed
Wed Jun 30 18:50:25 EAT 2010
Process J000 died, see its trace file
Wed Jun 30 18:50:25 EAT 2010
kkjcre1p: unable to spawn jobq slave process
Wed Jun 30 18:50:27 EAT 2010
Errors in file /oracle/admin/dlyx/bdump/dlyx_cjq0_16372.trc:
可以发现大量的J000,q000进程死掉了。
Ø 打开跟踪文件：
/oracle/admin/dlyx/bdump/dlyx_cjq0_16372.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/OraHome_1
System name: HP-UX
Node name: lsyxdb
Release: B.11.31
Version: U
Machine: ia64
Instance name: dlyx
Redo thread mounted by this instance: 1
Oracle process number: 10
Unix process pid: 16372, image: (CJQ0)
*** 2010-06-30 18:36:11.770
*** SERVICE NAME:(SYS$BACKGROUND) 2010-06-30 18:35:59.220
*** SESSION ID:(657.1) 2010-06-30 18:35:58.812
Waited for process J000 to initialize for 60 seconds
*** 2010-06-30 18:36:16.660
Process diagnostic dump for J000, OS id=26847
-------------------------------------------------------------------------------
loadavg : 0.20 0.23 0.30
Swapinfo :
Avail = 7761.29Mb Used = 7640.66Mb
Swap free = 120.62Mb Kernel rsvd = 1511.08Mb
Free Mem = 15.14Mb
F S UIDPID PPID C PRI NI ADDRSZ WCHAN STIME TTY TIME COMD
1401 Soracle 26847 1 0 128 20 e00000018b663700 2291 e000000175f1c100 18:34:55 ? 0:00 ora_j000_dlyx
*** 2010-06-30 18:36:55.052
Stack:
skgpgcmdout: read() for cmd /usr/bin/echo "set pagination off
bt 50
detach" | /opt/langtools/bin/gdb -quiet /oracle/OraHome_1/bin/oracle 26847 2>&1 | /bin/grep "#" timed out after 11.321 second
s
-------------------------------------------------------------------------------
从这段可以看出oracle在60秒内等待J000的启动。小型机维修并且可用的物理只有15.14MB。
可以猜想由于内存的不足，导致Oracle的进程无法正常启动，从而导致本次磁盘IO的异常，进而导致整个数据库服务器的异常。
这与之前的HP-UX系统报错也是吻合的：
Jun 30 17:35:27 lsyxdb cmnetd:Warning: process was unable to run for the last 6 seconds
Jun 30 17:38:58 lsyxdb telnetd:getpid: peer died: Error 0
通读了Oracle告警日志出现此报错跟发生几次当机的时间比较吻合，也无其他能引起当机的报错出现。
Ø 分析导致报错的原因：
服务器的物理内存是8gb,在利用oracle dbca创建实例的时候，Oracle默认将sga的大小设置为5gb,加上系统本身使用的1.7gb,在加上asm实例使用的200mb,oracle各种进程所占用的400mb左右，pga的大小900mb，已经超出了物理内存的最大值。当执行一些命令或者在oracle压力过大的时候就会导致由于内存不足进程无法创建或正常运行的情况发生，进而导致大量的换页，从而引起本地磁盘io暴涨，使系统崩溃。
Ø 调整措施：
将原有SGA的大小由默认的5GB调整为4106mb，在oracle压力较小的情况下剩余的物理内存控制在900MB左右，从而避免了由于内存不足而导致进程无法创建，内存不够使用而导致大量的换页的发生。以下是对Oracle参数调整后所作的测试。
3 测试：3.1 系统测试：
用不同的25个用户开了100个营销系统客户端，都创建了连接。并用不同的用户对正常用户计算，直到CPU被占用慢为止。整个系统，Oracle数据库都运行正常。
3.2 出错的情况分析及测试：
3.2.1 第一次出错：Ø 原因：执行find . –nane xxx命令来查找某些文件，导致系统当机。
Ø 分析： 测试发现在对大文件夹执行find命令的是需要数十mb的内存空间。
Ø 最新测试：在系统测试的高压环境下，对oracle安装目录和usr目录进行了find，都很顺利的完成了。
3.2.2 第二次出错：Ø 原因：创建一个几百兆的TAR包，导致系统当机。
Ø 分析：测试当执行tar打包的时候，会占用几十MB的内存。
Ø 最新测试：在系统测试的高压环境下，对一个1g的备份文件进行tar包，运行正常。
3.2.3 第三次出错：Ø 原因：没有任何操作，系统当机。
Ø 分析：当时各个模块都在修改程序、存储过程等，导致使用内存的一定增长，进程无法创建而当机。
Ø 最新测试：参见系统测试。
3.2.4 第四次出错：Ø 原因：调整了shared_pool_size,db_cache_size,等Pool的大小。重启当机。
Ø 分析：调整的值累加比原有的sga还要大32mb,从而导致了内存不够而失败，无法启动而当机。
Ø 最新测试：调小了SGA的大小后，剩余的内存一直维持在900mb左右，供系统进程，Oracle进程及pga使用。
在100个在线用户，并发使CPU占满，执行占资源的系统命令的共同情况下，整个测试系统运行正常，Oracle运行正常。系统日志跟oracle日志都没有异常报错出现。
4 目前内存的分配情况：lsyxapp#[/]kmeminfo
tool: kmeminfo 10.06 - libp4 9.435 - libhpux 1.303 - HP CONFIDENTIAL
unix: /stand/current/vmunix 11.31 64bit Montvale on host "lsyxapp"
core: /dev/kmem live
link: Thu Mar 11 11:04:16 EAT 2010
boot: Thu Jul 8 19:53:33 2010
time: Fri Jul 9 17:33:19 2010
nbpg: 4096 bytes
----------------------------------------------------------------------
Physical memory usage summary (in page/byte/percent):
Physical memory = 2089289 8.0g 100%
Free memory =214156 836.5m 10%
User processes = 1413198 5.4g 68% details with -user
Detached SHMEM = 624.0k0% details with -shmem
System =448161 1.7g 21%
Kernel =328949 1.3g 16% kernel text and data
Dynamic Arenas =143335 559.9m7% details with -arena
vx_global_kmcac = 1704266.6m1%
BTREE_NODE_OLA_ = 1398154.6m1%
SWAP_MISC_ARENA = 1267249.5m1%
spinlock_arena = 976638.1m0%
vm_pfn2v_arena = 853433.3m0%
Other arenas = 81340 317.7m4% details with -arena
Super page pool= 1434 5.6m0% details with -kas
Emergency pool = 465418.2m0% system critical reserve
UAREA's = 897635.1m0%
Overflow pte's = 1648164.4m1%
Static Tables =136910 534.8m7% details with -static
pfdat =102016 398.5m5%
vhpt = 1638464.0m1%
text = 901335.2m0% vmunix text section
bss = 554021.6m0% vmunix bss section
inode = 1792 7.0m0%
Other tables = 2164 8.5m0% details with -static
File Cache =119212 465.7m6% details with -ufc
5 总结：分析来看，此次出现的问题是由于Oracle创建实例使用的默认参数过大导致内存不足而引起的系统崩溃，与我的疏忽也有关系，通过下降Oracle的内存参数的值可以避免这个问题再次发生。
经验总结：
1.出现问题思想上不能一味的把问题归结到一个厂家上，这样是不公平的也不利于问题的解决。
2.在分配Oracle SGA大小的时候按照内存的%80的%80等原则来分是不准确的，需要考虑到进程的使用，系统的使用，ASM的使用，PGA的使用等多种因素，并要预留一部分内存空间给系统命令的使用，系统的扩展空间，这样才不至于发生有关内存的问题。按照Oracle的建议sga，asm 和其他Oracle进程(包括最大连接数的进程)的总和不要超过系统整个物理内存的70%，当然这个也是不一定的，需要在测试环境下多测试，多监控，多分析，最终找到一个系统运行最合适的值。
3.我们在查看Oracle告警日志的时候都要通读整个文件，不要草草一读了知，这样很容易就放过了报错的信息。一旦发现有trc文件报警，一定要hp小型机维修仔细查看trc文件内容，避免问题扩大，把问题扼杀在摇篮之中。最好是每天都把前一天的日志给仔细通读一遍。
4.在设置oracle sga的时候，Oracle推荐设置sga_target值，并且给其他pool_size设置一个最小值，避免oracle调整这些pool过小。
页:
[1]