EBS initialize cost horribly long time
I restored a 4TiB EBS volume(provisioned IOPS 16000, throughput 500MB/s) from a snapshot, and copying the data in the block to the instance store of the ec2 (I need the data to be in the instance store, and I think this can also be regarded as a initialize process.)
There's around 2.5TiB data to be copied, and copying has lasted over a week, while the disk's latency is still too high and the throughput is just 3~5MiB/s:
I know that a new restored EBS volume from snapshot is lazy loading but I also read from this blog post that there's a background process keeps doing this:
The replicated volume loads data in the background so that you can begin using it immediately. If you access data that hasn’t been loaded yet, the volume immediately downloads the requested data from Amazon S3, and then continues loading the rest of the volume’s data in the background
May I know how this background process works exactly? Since my initializing process(the copying process) is ongoing as well, will this background job runs as well?
- Newest
- Most votes
- Most comments
The overall process works based on disk access. You can try and initialize it faster by hitting every block of the disk to attempt to load it faster. Otherwise it may be beneficial for you to look into FRS https://aws.amazon.com/blogs/aws/new-amazon-ebs-fast-snapshot-restore-fsr/
Relevant content
- asked 2 years ago
- Accepted Answerasked 3 years ago
AWS OFFICIALUpdated 10 months ago- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 6 months ago
Could you elaborate more on "The overall process works based on disk access"? How it based on disk access? I know the FRS mechanism but just want to know how the initilize works in background when we use the disk normally.