R6服务器不稳定,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使用率不高，数据库负载也不高。没有发现相关的锁等待，数据库级没有发现明显问题

在日志目录中发现了大量的历史日志，可以根据条件进行删减。