预热Amazon EBS Volumes

Posted 2020-11-05

问题描述及分析处理：

最近在做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，如下：

[[email protected] ~]# 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