操作系统缓存导致的问题

1. 背景

在1月20号对某套数据库系统更换存储,存储从HP eva8400换到华为6800存储。这套数据库运行在RHEL 5.5 64位的vmware主机上,内存是64g,逻辑CPU 16。由于是虚拟机,整个迁移就由主机组完成,DBA就负责停一下数据库,主机组迁移完成后再通知DBA启一下数据库,整个过程非常easy,但就是这么个简单的过程,折腾了两天。

2. 问题描述

系统迁移完,21号一上班,业务就告状了,系统比平时慢很多,平时登录2秒左右,现在登录要10秒以上。
由于数据库参数没有任何变化,仅仅是重启了数据库,而业务的反应这么大,所以焦点一下子就到迁移的存储上去了,怀疑难道华为6800存储会这么差。诊断前也与业务反复确认过,业务是否有变更,业务很确信地告诉我们:没有。

3. 检查IO性能

先看一下服务器的性能数据:

而从监控历史的sar性能数据来看,迁移前WIO基本为0




从数据库的AWR比对报告来看,21日(2nd)的物理读和逻辑读比20日都小,但是db file scattered read和db file sequential read响应时间下降非常多。
db file sequential read的响应时间从0.01ms升高到9.32ms,而db file scattered read的响应时间从0.08升高到12.85ms。

4. 主机诊断存储

由于数据库参数没有任何变更,所以一开始问题的焦点就主要集中在存储的诊断上,主机人员检查存储的lun、链路等,由于才开始使用华为6800存储,主机组还不是很熟悉,到21号下午时检查到说链路不均衡,调整了下链路使均衡使用。由于临近下班,调整完后,从主机上的sar -u命令来看,%iowait降到8-10左右,但也有可能是临近下班,业务量下降了。但是从监控历史来看,以前的wio基本为0,所以感觉明天的IO性能估计还是有问题。
这一天我也看了看这套数据库上跑的SQL,说实在的SQL不是很好,全表扫描比较多,但是前面业务也说了,业务没有变更。就对一些明显地缺索引导致的全表扫描,提了一些创建索引的建议,业务表示21号晚上创建索引。
另外今天我也看了下主机的内存情况,发现配的大内存页基本都处理保留状态,我也没有太在意,认为可能还没有用上,看了眼数据库sga_max_size参数,确认配置是30g,认为等过段时间,保留内存就会变少了。

今天就这么过去了,晚上看了看,%iowait还是处于8-10左右的状态。
22号上班时,果然IO性能还是不行,主机组又开始满世界找问题,打电话给华为的支持,差点要把华为的支持拉到现场来批斗。

5.发现问题

在主机组检查存储同时,我也检查了下数据库的参数,但是这一看,就看出问题了。

db_cache_size只有64M,我彻底傻眼了,这个参数怎么会这样,难道有人改过?我就搜索整个数据库的alert日志,没有人修改过,这个参数一直是这样。上次数据库重启时间为2015年9月28日,从重启时的数据库alert信息来看,db_cache_size没有设置,隐含参数__db_cache_size为64M。这就表明,这个参数没有人动过,一直就是这样。

db_cache_size参数没有修改过,照道理华为6800的性能比老旧的HP eva8400要好很多,怎么IO性能就一下子变差了呢。
先不管了,把db_cache_size先设个20g再说。
ALTER SYSTEM SET db_cache_size=’20G’ SCOPE=BOTH;
设置完db_cache_size后再看sar -u的性能数据,%iowait就降为0了,再问业务,业务表示性能恢复了。

6. 思考与总结问题

数据库的db_cache_size参数前后肯定是一致的,没有发生变化,也就是说数据库的数据缓存大小没有发生变化。这个数据库使用的是文件系统,会不会是主机文件系统缓存了大量的数据,造成迁移前IO性能很好呢?大家讨论了下,有这个可能。

当前主机上的cached只有973M,大家表示没有在迁移前保留free的相关信息,迁移前是什么情况就不得而知了。
我翻了下我的secureCRT日志,找到了在2016年9月23号的这台机器的vmstat信息

从当时vmstat的信息来看,文件系统缓存大概有24g左右,所以应该就是这个原因。
整个性能问题原因总结如下:由于数据库的数据缓存只有64M,几乎可以忽略不计。在迁移存储前,文件系统缓存了24g的数据,从数据库上看到的物理读其实大部分都是从文件系统缓存中读取,所以IO性能很高。由于存储迁移,主机重启,文件系统缓存释放了,物理读都需要从存储上读取,这就造成IO性能比较差。从21号凌晨迁移完到22号,文件系统只缓存了900M左右的数据,所以也是IO一直比较慢的原因。
由于迁移没有涉及数据库参数的变化,所以整个性能故障诊断过程中没太关注数据库参数是否正确,其实在内存信息那块已经体现了可能数据库的内存存在问题。
在设置db_cache_size之前,大内存页的信息如下:

而设置完db_cache_size之后,大内存页的信息如下:

未设置db_cache_size之前,HugePages_Free和HugePages_Rsvd都比较高,这是因为SGA设置了30g,而实际上Oracle的db_cache_size和shared_pool没有使用那么多内存,大部分内存是被SGA保留,未真正用上。而设置db_cache_size后,就用上了,HugePages_Free和HugePages_Rsvd就下降了,这些信息被迁移前后数据库参数未变更给忽略了,这也是给自已提了一次醒,出现问题时应该怀疑并检查一切,不能自信,否则就会给诊断带来误区。

本篇文章已于3月1日首发于OCM之家:一次有趣的性能诊断
欢迎关注OCM之家公众号:

关于紫砂壶

感悟技术人生
此条目发表在Oracle性能问题分类目录,贴了标签。将固定链接加入收藏夹。

1 则回应给 操作系统缓存导致的问题

  1. lfree说:

    真神奇的迁移.
    跟我去年遇到一个有点相似.
    http://blog.itpub.net/267265/viewspace-2102914/

评论已关闭。