gc服务器慢的原因分析

最新推荐文章于 2024-03-29 17:09:50 发布

congbao6525

最新推荐文章于 2024-03-29 17:09:50 发布

阅读量310

点赞数

在工作环境中有一台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使用率不高，数据库负载也不高。没有发现相关的锁等待，数据库级没有发现明显问题
在日志目录中发现了大量的历史日志，可以根据条件进行删减。