HP小機問題分析及處理

1         問題描述

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: oracle@lsyxdb (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      UID   PID  PPID  C PRI NI             ADDR   SZ            WCHAN    STIME TTY       TIME COMD

1401 S   oracle 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[16101]: Warning: process was unable to run for the last 6 seconds

Jun 30 17:38:58 lsyxdb telnetd[25347]: 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      =        6   24.0k   0%  details with -shmem

System                =   448161    1.7g  21%

  Kernel              =   328949    1.3g  16%  kernel text and data

    Dynamic Arenas    =   143335  559.9m   7%  details with -arena

      vx_global_kmcac =    17042   66.6m   1%

      BTREE_NODE_OLA_ =    13981   54.6m   1%

      SWAP_MISC_ARENA =    12672   49.5m   1%

      spinlock_arena  =     9766   38.1m   0%

      vm_pfn2v_arena  =     8534   33.3m   0%

      Other arenas    =    81340  317.7m   4%  details with -arena

    Super page pool   =     1434    5.6m   0%  details with -kas

    Emergency pool    =     4654   18.2m   0%  system critical reserve

    UAREA's           =     8976   35.1m   0%

    Overflow pte's    =    16481   64.4m   1%

    Static Tables     =   136910  534.8m   7%  details with -static

      pfdat           =   102016  398.5m   5%

      vhpt            =    16384   64.0m   1%

      text            =     9013   35.2m   0%  vmunix text section

      bss             =     5540   21.6m   0%  vmunix bss section

      inode           =     1792    7.0m   0%

      Other tables    =     2164    8.5m   0%  details with -static

  File Cache          =   119212  465.7m   6%  details with -ufc

5         總結：

分析來看，此次出現的問題是由於Oracle建立例項使用的預設引數過大導致記憶體不足而引起的系統崩潰，與我的疏忽也有關係，透過下降Oracle的記憶體引數的值可以避免這個問題再次發生。

 

經驗總結：

1.出現問題思想上不能一味的把問題歸結到一個廠家上，這樣是不公平的也不利於問題的解決。

2.在分配Oracle SGA大小的時候按照記憶體的%80的%80等原則來分是不準確的，需要考慮到程式的使用，系統的使用，ASM的使用，PGA的使用等多種因素，並要預留一部分記憶體空間給系統命令的使用，系統的擴充套件空間，這樣才不至於發生有關記憶體的問題。按照Oracle的建議sga，asm 和其他Oracle程式(包括最大連線數的程式)的總和不要超過系統整個實體記憶體的70%，當然這個也是不一定的，需要在測試環境下多測試，多監控，多分析，最終找到一個系統執行最合適的值。

3.我們在檢視Oracle告警日誌的時候都要通讀整個檔案，不要草草一讀了知，這樣很容易就放過了報錯的資訊。一旦發現有trc檔案報警，一定要仔細檢視trc檔案內容，避免問題擴大，把問題扼殺在搖籃之中。最好是每天都把前一天的日誌給仔細通讀一遍。

4.在設定oracle sga的時候，Oracle推薦設定sga_target值，並且給其他pool_size設定一個最小值，避免oracle調整這些pool過小。