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

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

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-07-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

新痛点:APT组织PawnStorm 0Day如何绕过Java点击播放保护

几个月以前,趋势科技发现了APT组织Pawn Storm利用之前未经披露的Java漏洞(CVE-2015-2590)进行攻击。在那之后,我们注意到一个被用于染过...

1946
来自专栏FreeBuf

Android 5.x漏洞:黑客可以绕过屏幕密码进入系统

很多Android用户会选择使用锁屏密码保护设备,但最新爆出的漏洞却令人震惊:任何人无需复杂的操作即可绕过锁屏直接进入你的系统! 攻击者可以通过漏洞导获取上锁...

23010
来自专栏IT笔记

记一次JavaWeb网站技术架构总结

题记 工作也有几多年了,无论是身边遇到的还是耳间闻到的,多多少少也积攒了自己的一些经验和思考,当然,博主并没有太多接触高大上的分布式架构实践,相对比较零碎,随时...

46411
来自专栏沃趣科技

【Oracle 12c Flex Cluster专题 】— Leaf Node的故障迁移

原文链接 http://allthingsoracle.com/oracle-flex-cluster-leaf-node-failover/ 译者 周天鹏...

3559
来自专栏FreeBuf

打开文件夹就运行?COM劫持利用新姿势

*本文原创作者:菠菜,本文属FreeBuf原创奖励计划,未经许可禁止转载 打开文件夹就能运行指定的程序?这不是天方夜谭,而是在现实世界中确实存在的。利用本文探讨...

2298
来自专栏云计算教程系列

如何在Debian上安装MutliCraft

PS:本文撰写前已查询相关法律,本文内容不违反《互联网文化管理暂行规定》,遵守EULA协议,请勿举报。

1603
来自专栏程序猿DD

自建API网关「架构设计篇」

阅读对象 传统企业正在做微服务架构转型的开发人员或者架构师,希望本文对您能起到一定的引导作用。 API网关介绍 网关一词较早出现在网络设备里面,比如两个相互独立...

1.3K7
来自专栏aCloudDeveloper

UNIX环境高级编程笔记之文件I/O

一、总结   在写之前,先唠几句,《UNIX环境高级编程》,简称APUE,这本书简直是本神书,像我这种小白,基本上每看完一章都是“哇”这种很吃惊的表情。其实大概...

22710
来自专栏王亚昌的专栏

iostat命令使用

天刚上线了一台server,观察了一下,发现io比较高,想到了iostat命令,观察了一下(每隔一秒打印一次),发现有一个守护进程每隔几秒就写一次IO,再top...

802
来自专栏ThoughtWorks

无法登录的用户

自从ins项目上线以后,团队其他成员都纷纷下了项目,只留下他这个项目经理留在一线解决问题。登录这块总是出现问题,上次就出现过一次,不过上次是机房网络原因,而这次...

1181

扫码关注云+社区

领取腾讯云代金券