Why?
What actually happens when you restore a snapshot is that the volume is provisioned for you and a pointer set up to the snapshot in S3.
However, the data is only physically transferred to EBS when it is first accessed, not in a steady fashion. To that end, if you want to maximize performance of a volume after restoring from snapshot is is necessary to touch the entire volume. This is referred to as "pre-warming".
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-prewarm.html
When you create any new EBS volume (General Purpose (SSD), Provisioned IOPS (SSD), or Magnetic) or restore a volume from a snapshot, the back-end storage blocks are allocated to you immediately. However, the first time you access a block of storage, it must be either wiped clean (for new volumes) or instantiated from its snapshot (for restored volumes) before you can access the block. This preliminary action takes time and can cause a 5 to 50 percent loss of IOPS for your volume the first time each block is accessed. For most applications, amortizing this cost over the lifetime of the volume is acceptable. Performance is restored after the data is accessed once.
However, you can avoid this performance hit in a production environment by writing to or reading from all of the blocks on your volume before you use it; this process is called pre-warming. Writing to all of the blocks on a volume is preferred, but that is not an option for volumes that were restored from a snapshot, because that would overwrite the restored data. For a completely new volume that was created from scratch, you should write to all blocks before using the volume. For a new volume created from a snapshot, you should read all the blocks that have data before using the volume.
Here is good guide to benchmarkion EBS volumes:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/benchmark_piops.html
Here is good guide to benchmarkion EBS volumes:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/benchmark_piops.html
No comments:
Post a Comment