ITPub博客

首页 > Linux操作系统 > Linux操作系统 > IO优化案例一则

IO优化案例一则

原创 Linux操作系统 作者:BTxigua 时间:2009-03-27 17:15:52 0 删除 编辑
我把我的整个过程写在这里,希望能给大家提供一个思路和借鉴。

环境:
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在写数据文件的时候是针对修改了的数据块进行更改写入,是随机小数据块写入,在磁盘上寻道的时间比较长,所以写入的量不大,但是磁盘非常的忙。同时,我也认为磁盘没有做条带化,所以才导致这个结果。

    一切以事实为准。所以我向原厂确认两点:
1)altibase数据库在checkpoint的时候写入的策略。原厂工程师最终答复:
    发生 checkpoint 的时候,对dirty page的flush,是根据数据文件顺序写, 而且是写好一个写另一个。
    第一次发生checkpoint 的时候 ,mydb-0-0, mydb-0-1, mydb-0-2..(位于/altibase_dbs1),根据数据文件的顺序进行flush。
    第二次发生checkpoint 的时候 ,mydb-1-0, mydb-1-1, mydb-1-2..(位于/altibase_dbs2),根据数据文件的顺序进行flush。
    第三次发生checkpoint 的时候 ,mydb-0-0, mydb-0-1, mydb-0-2..(位于/altibase_dbs1),根据数据文件的顺序进行flush。
    ...
mydb-0-n是一个一个的物理文件(每个大小我这里定义的是1G),altibase没有表空间的概念。在没有做条带的文件系统中,这种写入策略就会导致磁盘写入效率比较低。

2)找来emc原厂的工程师,现场检查每个/altibase_dbs1,/altibase_dbs2,/altibase_logs中pv(hdiskpower)在物理磁盘上是如何分布的?最终检查的结果终于证实了我的猜想,只做了raid1。
    emc在划分的时候,将一块物理硬盘(146G)分成10个 volumn (每个14g),然后从第一块硬盘中取出一个volumn,比如volumn11,从第二块硬盘中取出一个volumn,比如volumn21,..,从第九块硬盘中取出一个volumn(volumn91),这9个volumn组成一个文件系统/altibase_dbs1。然后volumn12,volumn22,...,volumn92组成文件系统/altibase_dbs2。
然后volumn13,volumn23,...,volumn93组成文件系统/altibase_logs。

这样,每个物理硬盘中还有其他的volumn,其余的volumn则被其他的系统使用,主要是被我们另一个oracle数据库使用,oracle的数据库比较繁忙。所以现在就比较清楚,为什么出现前面的情况了。altibase的数据文件mydb-0-n每个是1g,而我们划分的volumn每个是 14g,基本上每个mydb-0-n是在同一个volumn中的,也就是在同一个物理硬盘中,同时这个物理硬盘还被其他的oracle数据使用,所以 altibase本身的写入量虽然不大,但是会出现busy 100%的情况。

解决方案

问题已经比较清楚了,我当时建议优化可以考虑从存储、主机、数据库3个方面来做:
1、主机级
当前lv创建在参数设置不是很合理。当前我们配置的INTER-POLICY:minimum ,也就是说数据在写入磁盘的尽量分布在最少的盘上,如果IO的量比较大,就容易造成单块盘的busy过高,引起等待。
建议重新创建vg,并且打开条带化写入的功能,条带化应该能缓解硬盘的IO压力。

2、存储级
1)加cache板,我们还有16G的cache板没加上去,加16G的cache在存储上,应该有比较明显的效果。但是当时emc回复需要下电才能加板,那就存在存储在下电以后无法起来,所以操作的风险很大。(最终还是加了cache板,因为最后确认不需要下电)。
2)做raid0策略。这个过于复杂,对我们的系统影响太大,所以实际上不可行。

3、数据库级
altibase数据库连接比较多,消耗了很多的物理内存,将连接数能降下来一些,也可以改善主机的情况。
对于altibase的写入策略,如果同时写多个数据文件,那也存在问题。因为同时打开,要占用内存,而且文件很大,对内存的占用也不少。这种策略上修改也比较困难,也不是短时间就可以解决的。

主机级的操作影响的范围最小,效果最好,但是也最麻烦。我将/altibase_dbs1,/altibase_dbs2,/altibase_logs 所有涉及的物理硬盘全部找出来,以及上面划分的pv的情况,以及每个pv给哪个系统使用了,然后挑选负担比较轻的物理硬盘中的volumn,组成 /altibase_dbs1和/altibase_dbs2,在主机层打开条带功能。

vg重建方案如下:
PV       逻辑分区编号 物理硬盘编号 该物理硬盘上其他的逻辑分区 oracle占用的逻辑分区数
hdiskpower4      0200 1d,da 1b0-1c0-1d0-1e0-1f0-200-210-220-230-240-2e6 5
hdiskpower5      0201 1a,ca 1b1-1c1-1d1-1e1-1f1-201-211-221-231-241-2e7 5
hdiskpower6      0202 1b,da 1b2-1c2-1d2-1e2-1f2-202-212-222-232-242-2e8 5
hdiskpower7      0203 1c,db 1b3-1c3-1d3-1e3-1f3-203-213-223-233-243-2e9 5
hdiskpower8      0204 1d,cb 1b4-1c4-1d4-1e4-1f4-204-214-224-234-244-2ea 5
hdiskpower9      0205 1a,db 1b5-1c5-1d5-1e5-1f5-205-215-225-235-245-2eb 5
hdiskpower10     0206 1b,cb 1b6-1c6-1d6-1e6-1f6-206-216-226-236-246-2ec 5
hdiskpower11     0207 1c,ce 1b7-1c7-1d7-1e7-1f7-207-217-227-237-247-2ed 6
hdiskpower12     0208 1d,dc 1b8-1c8-1d8-1e8-1f8-208-218-228-238-248-2ee 6
hdiskpower13     0209 1a,cc 1b9-1c9-1d9-1e9-1f9-209-219-229-239-249-2ef 6
hdiskpower14     020A 1b,dc 1ba-1ca-1da-1ea-1fa-20a-21a-22a-23a-24a-2f0 6
hdiskpower15     020B 1c,dd 1bb-1cb-1db-1eb-1fb-20b-21b-22b-23b-24b-2f1 6
hdiskpower16     020C 1d,cd 1bc-1cc-1dc-1ec-1fc-20c-21c-22c-23c-24c-2f2 6
hdiskpower17     020D 1a,dd 1bd-1cd-1dd-1ed-1fd-20d-21d-22d-23d-24d-2f3 6
hdiskpower18     020E 1b,cd 1be-1ce-1de-1ee-1fe-20e-21e-22e-23e-24e-2f4 6
hdiskpower19     020F 1c,cc 1bf-1cf-1df-1ef-1ff-20f-21f-22f-23f-24f-2f5 5
hdiskpower20     0210 1d,da 1b0-1c0-1d0-1e0-1f0-200-210-220-230-240-2e6 5
hdiskpower21     0211 1a,ca 1b1-1c1-1d1-1e1-1f1-201-211-221-231-241-2e7 5
hdiskpower54     0063 1b,d4 014-03b-063-08b-103-12b-153-17b-1a3 4
hdiskpower55     0064 1c,d5 015-03c-064-08c-104-12c-154-17c-1a4 3
hdiskpower56     0065 1d,c5 016-03d-065-08d-105-12d-155-17d-1a5 3
hdiskpower57     0066 1a,d5 017-03e-066-08e-106-12e-156-17e-1a6 3
hdiskpower58     0067 1b,c5 018-03f-067-08f-107-12f-157-17f-1a7 3
hdiskpower59     0068 1c,c6 009-040-068-090-0b8-0e0-108-130-158-180-198 4
hdiskpower60     0069 1d,d6 012-041-069-091-0b9-0e1-109-131-159-181-1a1 4
hdiskpower61     006A 1a,c6 01a-042-06a-092-0ba-0e2-10a-132-15a-182-1a9 4
hdiskpower62     006B 1b,d6 01b-043-06b-093-0bb-0e3-10b-133-15b-183-1aa 5
hdiskpower63     006C 1c,d7 01c-044-06c-094-0bc-0e4-10c-134-15c-184-1ab 5
hdiskpower64     006D 1d,c7 01d-045-06d-095-0bd-0e5-10d-135-15d-185-1ac 5
hdiskpower65     006E 1a,d7 01e-046-06e-096-0be-0e6-10e-136-15e-186-1ad 6
hdiskpower66     006F 1b,c7 01f-047-06f-097-0bf-0e7-10f-137-15f-187-1ae 6
hdiskpower67     0070 1c,c8 011-048-070-098-0c0-0e8-110-138-160-188-1a0 6
hdiskpower68     0071 1d,d8 019-049-071-099-0c1-0e9-111-139-161-189-1a8 6


lv的划分需要尽量跨在多个物理硬盘上,dbs1和dbs2的lv最好能避开oracle,所以需要尽量划在oracle占用比较少的物理硬盘上,建议的lv划分如下:
lv00 (/altibase_dbs1): hdiskpower 4,5,54,55,56,57,6,7,8,9,10,11    -12个pv
lv01 (//altibase_dbs2): hdiskpower 20,21,58,59,60,61,12,13,14,15,16,17    -12个pv
lv02 (/altibase_logs) : hdiskpower 18,19,62,63,64,65,66,67,68       -9个pv

lv 的Stripe Size为64K。stripe width 为4。

后记:
条带后的效果非常明显,同步不再存在积压情况,在条带之后的1年,没有再出现任何问题。
    其实这也不是第一次出现问题。以前也出现过,只不过一般也都是半年才出现个一次。

其实这个事情上给我们几个教训:
1、系统在设计阶段你就得做好规划。从底向上,得有一个通盘的考虑。
2、给EMC这样的原厂厂家提需求的时候,最好能细节化。比如详细的你对binfile要求。在后面的另一个项目中,又郁闷了一次。新买的DMX4存储,在美国就给灌好了binfile,这个binfile我没有提很多细节的东西。结果因为赶进度,没有时间再重新调整了。存储的划分没有达到我的一个比较理想的情况。
3、原厂的话不能尽信。很多的东西你必须得亲眼看到才行。这也是无数次的教训了。
4、有时候你要坚持你的判断,相信自己。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10867315/viewspace-580381/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-01-31

  • 博文量
    101
  • 访问量
    281195