gc伺服器慢的原因分析 (r6筆記第14天)
在工作環境中有一臺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使用率不高，資料庫負載也不高。沒有發現相關的鎖等待，資料庫級沒有發現明顯問題
在日誌目錄中發現了大量的歷史日誌，可以根據條件進行刪減。