IO优化例一则.docVIP

IO优化案例一则 IO优化案例一则 个人分类：Altibase 我把我的整个过程写在这里，希望能给大家提供一个思路和借鉴。 环境： OS:AIX 5307 DB:ALTIBASE 3 EMC DMX1000 第一次出现问题 问题现象： 在白天的业务高峰期，210G内存被消耗完。内存数据库同步积压，积压的日志文件数达到2000个多个，也出现了SWAP OUT的情况。主机相应变慢，但还没有hang住。 在出现这个问题的时候，首先检查了系统的内存占用情况，发现内存被消耗完，noncomp（文件型页面缓存）占用比较高，同时IO也存在等待的情况（当时的情况没有保存，无法重现了）。因为一直运行也比较正常，存储层的东西没怎么修改过，所以当时尝试修改了系统参数max_perm%和 min_perm%，修改之后，noncomp占用依然，因为这两个参数只是一个大概的值，并不会严格限定noncomp内存的使用，于是在加上参数 strict_maxperm = 1，严格限定noncomp的内存占用，修改的结果是导致同步进程出现异常，无法正常进行复制。时间比较紧迫，就采用了以下方法解决： 1、停止复制。 2、就直接从其他的逻辑分区上划了25个G的内存过来。 3、当天晚上再重做一次全同步。 问题解决。 ============================================ 第二次出现问题 在第一次解决之后，观察了几天，系统还算稳定。但是在半个月之后，又出现了前面的问题。已经尝试加过内存，不能再继续加了，明显治标不治本，而且我们也没那么多内存来不停的加。 当时就停止复制，释放内存，当天晚上再重新全同步。但这只能是权宜之计，不能隔段时间就做一次这样的全同步，决心彻查一下问题。 在对当时的topas，nmon等的结果分析，我认为，主要是因为磁盘的IO等待太高，导致文件的读写被拖延，从而导致noncomp的内存占用不断攀升。我发现一个现象，从io层面看，io分布不均匀，在一个时间段中，总有一个hdiskpower busy为100％，但是大约1个小时之后，会换另外一个hdiskpower busy为100％，而且，这个100％的盘实际读写的量并不是很高，大概为6M/s。当时我的判断就是存在热点盘，并且在存储层面没有做raid 0。 因为这个问题几次出现，影响到我们的业务，决定彻查。于是找了EMC原厂的人过来的人过来商讨优化方法，emc建议抓一天的数据做一个存储分析，看看是否存在热点盘。几天以后，emc的结果出来了，emc认为没有单独的热点盘，全部盘都是热点盘，都在满负荷运行。另外，关于我提出的没有做条带的疑惑，EMC的答复是条带肯定做了。 emc给出的建议是： 1）扩充现有的内存(增加2块16GB cache) 2）另外发现只有几个前端端口的IOPS较高，其他的前端端口比较空闲，建议把繁忙LUN再增加对前端端口的映射。 这个存储其实也比较老了，存储上挂了好几个业务系统，磁盘都忙也是正常的。而且EMC是以24小时为单位看的，所以我觉得得到这样的结果也正常，因为我们busy100％的盘始终在轮换，从整体的效果来看，每块盘都忙。 针对EMC的解决方案，扩充cache板，也许对系统有一定的提升，但是实际的效果很难说，我觉得基本不会有太大的提升，能提升个5%也就差不多了。 想要解决这个问题，还是得找其他的办法。另外，我还是怀疑条带没做，还想继续检查确认条带的问题。 在系统中，我们在crontab中布置了一个nmon作业，来监控系统的使用。于是我就找了其中的一天分析。结果发现一个比较奇怪的现象。altibase数据库有3个文件系统： /altibase_dbs1 /altibase_dbs2 /altibase_logs 数据在写入的时候，会先写/altibase_dbs1，一段时间之后，再写/altibase_dbs2，然后再写 /altibase_dbs1...，如此交替。/altibase_logs则始终在写。写入的量上/altibase_logs为（dbs1＋dbs2）中写入的量的2倍。这三个文件系统都基本不存在读。如果按照这个写入的来量来推算，那应该是logs下面的盘比较忙，但是实际的情况是dbs1和dbs2的盘非常忙，正在写入的盘busy为100％，但是logs正在写入的盘busy只有50％。 因为不清楚altibase在做checkpoint的时候，数据块的写入策略，所以比较难以解释。当时猜想altibase在写数据文件的时候是针对修改了的数据块进行更改写入，是随机小数据块写入，在磁盘上寻道的时间比较长，所以写入的量不大，但是磁盘非常的忙。同时，我也认为磁盘没有做条带化，所以才导致这个结果。 一切以事实为准