gc伺服器慢的原因分析

在工作環境中有一臺gc的伺服器，已經好幾年沒有動過了，上面安裝著gc的服務和資料庫，也就說gc裡面的HttpServer，資料庫,webcache都在這臺伺服器上。
大家在訪問gc的時候，感覺有些時候訪問很慢，儘管是內網，但是還是有很大的延遲的感覺，大家認為可能是監控的機器比較多了，也就沒有在意，今天我抽空檢視了下這臺機器，還是發現了一些問題。
首先看看gc的服務是否正常。我們也可以使用opmn來檢測。
$ ./opmnctl status
Processes in Instance: EnterpriseManager0.cyoumon.cyou.com
-------------------+--------------------+---------+---------
ias-component      | process-type       |     pid | status 
-------------------+--------------------+---------+---------
DSA                | DSA                |     N/A | Down   
HTTP_Server        | HTTP_Server        |   20850 | Alive  
LogLoader          | logloaderd         |   29381 | Alive  
dcm-daemon         | dcm-daemon         |   29428 | Alive  
OC4J               | home               |   20851 | Alive  
OC4J               | OC4J_EMPROV        |   20852 | Alive  
OC4J               | OC4J_EM            |   20853 | Alive  
OC4J               | OCMRepeater        |   20855 | Alive  
WebCache           | WebCache           |   20863 | Alive  
WebCache           | WebCacheAdmin      |   20857 | Alive
這也就是例行檢查，如果服務有問題，就不只是卡了。不過還是看了下，簡單驗證一下。
然後就是檢視系統的情況
檢視系統，我分為以下幾個部分來看。
首先檢視系統版本，發現這是一個比較老的版本，還是redhat 4
$ cat /etc/issue
Red Hat Enterprise Linux AS release 4 (Nahant Update 8)
Kernel \r on an \m
檢視CPU的資訊如下:
有8個物理CPU,8個邏輯CPU，CPU算是比較老的配置
$ ksh cpuinfo.sh
**************************************
CPU Physical NO:  8
CPU Processor NO:  8
CPU Core NO:  cpu cores : 1
CPU model name : Intel(R) Xeon(R) CPU E5504 @ 2.00GHz
**************************************
這個配置在現在看來還是比較緊俏的。
但是這個肯定不是最根本的原因，不能一有問題就全部歸結在硬體上，這個也是硬傷，不會說改進就改進，畢竟很多服務跑了很多年了。
我們來看看系統的負載
這個時候還是使用傳統的top
可以看到還是存在大量的swap現象,
top - 14:07:46 up xxxx days, 19:18,  4 users,  load average: 0.05, 0.16, 0.12
Tasks: 175 total,   1 running, 174 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.7% us,  0.1% sy,  0.0% ni, 98.7% id,  0.5% wa,  0.0% hi,  0.0% si
Mem:  16430320k total, 16375716k used,    54604k free,     9680k buffers
Swap:  8385920k total,  3468324k used,  4917596k free,  4501616k cached
使用vmstat檢視swap的情況
$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0 3483652  50404   4896 4480752   14    4    48    42    0     0  1  0 99  0
 0  0 3483652  51260   4936 4480712    0    0     0   332 1062  2594  0  0 100  0
 0  0 3483652  52108   4936 4480712    0    0     0     0 1004  2565  0  0 100  0
 0  0 3483652  52116   4936 4480712    0    0     0     0 1005  2468  0  0 100  0
 0  0 3483652  55988   4940 4480776    0    0    16    92 1119  2705  0  0 99  0
可以從中看出很明顯的swap,大概是3G的樣子
如果這個時候來看系統的整體負載，還是使用sar,可以看到idle基本都在99%左右，所以說盡管在這樣的情況下，還是存在問題，CPU儘管配置不高，但是利用率也確實不高。 
$ sar
07:40:01 AM       CPU     %user     %nice   %system   %iowait     %idle
07:50:01 AM       all      0.49      0.00      0.10      0.08     99.33
08:00:01 AM       all      0.63      0.00      0.12      0.16     99.09
08:10:01 AM       all      0.60      0.00      0.13      0.40     98.87
08:20:01 AM       all      0.62      0.00      0.11      0.12     99.15
08:30:01 AM       all      0.65      0.00      0.11      0.11     99.12
08:40:01 AM       all      0.49      0.00      0.10      0.09     99.32
08:50:01 AM       all      0.48      0.00      0.13      0.29     99.09
09:00:01 AM       all      0.54      0.00      0.10      0.07     99.30
09:10:01 AM       all      0.67      0.00      0.14      0.35     98.84
09:20:02 AM       all      0.66      0.00      0.13      0.28     98.92
09:30:01 AM       all      0.66      0.00      0.12      0.13     99.10
09:40:01 AM       all      0.61      0.00      0.11      0.14     99.14
09:50:02 AM       all      0.50      0.00      0.13      0.25     99.12
10:00:01 AM       all      0.55      0.00      0.11      0.19     99.15
10:10:01 AM       all      0.59      0.00      0.13      0.31     98.98
10:20:01 AM       all      0.64      0.00      0.16      0.65     98.55
10:30:01 AM       all      0.79      0.00      0.19      0.76     98.26
10:40:01 AM       all      0.70      0.00      0.15      0.43     98.72
10:50:01 AM       all      0.62      0.00      0.13      0.12     99.13
11:00:01 AM       all      0.87      0.00      0.18      0.86     98.09
11:10:01 AM       all      0.88      0.00      0.29      1.04     97.79
11:20:01 AM       all      0.81      0.00      0.28      0.94     97.96
11:30:01 AM       all      0.87      0.00      0.18      0.50     98.45
11:40:02 AM       all      0.66      0.00      0.14      0.32     98.88
11:50:01 AM       all      0.78      0.00      0.66      0.75     97.81
Average:          all      0.69      0.00      0.17      0.53     98.61
檢視核心引數，發現Memlock還是最低的預設值32，這個時候可以嘗試修改memlock
oracle              soft    memlock    unlimited
oracle              hard    memlock    unlimited
檢視核心中配置了Hugepage，但是實際來看，還是沒有使用到。
$ cat /proc/meminfo | grep -i page
PageTables:     387504 kB
HugePages_Total:  5121
HugePages_Free:   5121
Hugepagesize:     2048 kB
可以使用Oracle提供的指令碼來檢視Hugepage的推薦配置。
$ ./hugepage_setting.sh
Recommended setting: vm.nr_hugepages = 3075
系統級的檢查大體就是這些，我們來看看資料庫級的情況
檢視了session總數載50個左右，還是使用率不高，歸檔一兩個小時切一次，資料庫層面沒有發現任何的阻塞和鎖等待。
同時檢視資料庫的負載，都是一個很低的值。
這個時候發現有很多的歷史日誌，
  但是在部分日誌目錄下存在大量日誌檔案，ls不可用
比如在adump目錄下，使用ls的時候都會出錯。
[/adump]$ ll *.aud|wc -l
bash: /bin/ls: Argument list too long
0
原來下面有不少的檔案，但是都是好幾年前的了。 
$ ll |wc -l
32468
其它幾個目錄下也都有類似的問題，所以這類問題也是一個因素，可以根據條件進行過濾，刪除掉很早的日誌檔案。
所以綜上所述，整體的分析結論如下： 
資料庫的硬體資源比較舊，系統是RHEL4，CPU資源相對比較緊俏
系統的負載不高，但是有swap的爭用，可以透過調整memlock進行改進
資料庫hugepage沒有生效，配置large page或者Hugepage
資料庫級session使用率不高，資料庫負載也不高。沒有發現相關的鎖等待，資料庫級沒有發現明顯問題
在日誌目錄中發現了大量的歷史日誌，可以根據條件進行刪減。