问题描述及分析处理:

最近在做AWS Cloud从CentOS6.9升级到CentOS7.4.1708,系统上跑着oracle数据库,数据量大概1.5T,准备了一个全新的CentOS7.4.1708 instance,


Oracle数据也都rman还原好了,然后对新的instance做AMI,再用这个AMI重新launch一个instance,这个instance起来之后,要添加oracle redo文件组,命令如下:


ALTER DATABASE ADD LOGFILE GROUP 1 ('/redo1/redo0101.log','/redo3/redo0102.log') SIZE 5000M BLOCKSIZE 512 REUSE;


执行的大约30min还没有结束(测试环境5min执行完成),于是查看系统的负载情况,发现CPU,memory都没有瓶颈,然后又看了一下磁盘IO,如下:


[root@ec2-xxx-01 ~]# sar -d 1 5
Linux 3.10.0-693.17.1.el7.x86_64 (ec2-xxx-01) 05/13/2018 _x86_64_(8 CPU)
07:02:55 AM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
07:02:56 AM  dev259-0     58.00  14336.00      0.00    247.17     30.06    514.72     17.24    100.00
07:02:56 AM  dev259-1     72.00  17408.00     64.00    242.67     33.00    464.58     13.89    100.00
07:02:56 AM  dev259-2      2.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
07:02:56 AM  dev259-3      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
07:02:56 AM  dev259-4      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
07:02:56 AM  dev253-0      4.00      0.00     64.00     16.00      1.00    260.50    250.00    100.00

07:02:56 AM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
07:02:57 AM  dev259-0     47.00  11264.00      0.00    239.66     30.15    559.83     21.28    100.00
07:02:57 AM  dev259-1     86.00  20480.00     96.00    239.26     32.87    412.72     11.63    100.00
07:02:57 AM  dev259-2      3.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
07:02:57 AM  dev259-3      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
07:02:57 AM  dev259-4      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
07:02:57 AM  dev253-0      6.00      0.00     96.00     16.00      1.00    227.50    166.50     99.90

07:02:57 AM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
07:02:58 AM  dev259-0     54.00  13312.00      0.00    246.52     30.31    681.20     18.52    100.00
07:02:58 AM  dev259-1     63.00  15360.00     64.00    244.83     33.41    466.29     15.87    100.00
07:02:58 AM  dev259-2      2.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
07:02:58 AM  dev259-3      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
07:02:58 AM  dev259-4      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
07:02:58 AM  dev253-0      4.00      0.00     64.00     16.00      1.41    225.25    250.00    100.00


有两块盘磁盘的使用率%util是100%,await也高达681,tps即相当于iops还不到100,这可是AWS instance_type为m5.2xlarge的实例,AWS的EBS不可能这么差吧,当时就比较疑惑,难道AWS也这么水,


于是上AWS网站上面查找原因,最后发现,从snapshot还原的磁盘,需要initialization(即预热pre-warming),新建的instance却不需要initilization。


据AWS说,没有initilizaion的磁盘性能会下降50%。那么该如何预热EBS呢?AWS也给出了处理方法,使用系统自带的工具dd或者第三方磁盘IOPS测试工具fio.这里不再详细讲述如何预热磁盘,本文主要是想告诉大家 AWS snapshot还原的


EBS,需要提前预热,否则性能会下降很多,如果读者有兴趣,可以参考如下AWS链接了解如何预热.


参考链接:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html