I am looking for a answer for a question over Amazon EC2.
As we can add multiple EBS which can be of 1TB in size, so how many of them i can add on a single EC2 instance?
Couldn't find the answer on goolge if there is someone who've experienced it or can refer something, that will be great help thanks.
The maximum number of volumes that your instance can have depends on the operating system. When considering how many volumes to add to your instance, you should consider whether you need increased I/O bandwidth or increased storage capacity.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_limits.html
For Linux, there is apparently a soft (recommended) limit of 40, while for Windows there is a hard limit, which can be 26 or 17 depending on the virtualization implementation in use.
Note also that most EBS volumes can be up to 16 TB in size rather than 1 TB, which is a limit that only applies to the legacy magnetic volume type.
Related
My question is about disks in Google Cloud.
I can’t understand why do we need to increase the disk capacity in order to increase performance (transfer/read/write). If the disks are not local, then data is transferred over the network between the VM and the disk, that I understand.
Can someone explain in simple clear words, why do we need to increase the disk capacity from 500GB to 1TB? How does this affect the transfer / read / write speed?
If it is not difficult, could you exmplain some simple example?
Thanks you very much.
This is how GCP is designed.
You can have a look at how the IOPS changes with capacity increase and machine type (like N1, N2, number of CPU's).
Example:
For example, consider a 1,000 GB SSD persistent disk attached to an
instance with an N2 machine type and 4 vCPUs. The read limit based
solely on the size of the disk is 30,000 IOPS. However, because the
instance has 4 vCPUs, the read limit is restricted to 15,000 IOPS.
Also have in mind that:
Performance also depends on the number of vCPUs on your VM instance due to network egress caps on write throughput.
Example:
In a situation where persistent disk is competing with IP traffic for
network egress bandwidth, 60% of the maximum write bandwidth goes to
persistent disk traffic, leaving 40% for IP traffic. Click below to
see an example of how to calculate the maximum persistent disk write
traffic that a VM instance can issue.
To optimize your disk performance you can do the following:
- change disk size (thus increasing IOPS)
- change machine type (to the one with higher network cap limit)
Here you can read how VM type affects GCP network caps.
As far as I can tell from my own experience and from what I have read, there are very few situations in which one wouldn't want to use EBS over instance store. However, instance store is generally faster for disk read/writes due to it's being physically attached to the EC2. How much faster, and whether it is faster in all cases, I don't know.
So, what I am curious about, if anyone out there has had some experience with any of these, is the relative speed/performance of:
An EC2 using instance store vs a non-storage-optimized EC2 using EBS (of any storage type)
An EC2 using instance store vs a storage-optimized (I3) EC2 using EBS
An EC2 using instance store vs a non-storage-optimized EC2 using some kind of EBS RAIDing
A non-storage-optimized EBS-backed EC2 vs a storage-optimized EC2 vs an EC2 with an EBS RAID configuration
All of the above vs EBS-optimized instances of any type.
The more specific and quantifiable the answers the better -- thanks!
Now Available – I3 Instances for Demanding, I/O Intensive Applications claims that Instance Store on i3 instances:
can deliver up to 3.3 million IOPS at a 4 KB block and up to 16 GB/second of sequential disk throughput.
Coming Soon – The I2 Instance Type – High I/O Performance Via SSD claims that Instance Store on i2 instances:
deliver 350,000 random read IOPS and 320,000 random write IOPS.
Amazon EBS Volume Types lists:
General Purpose SSD: Maximum 10,000 IOPS/Volume
Provisioned IOPS SSD: Maximum 20,000 IOPS/Volume
Throughput Optimized HDD: Maximum throughput 500 MiB/s (Optimized for throughput rather than IOPS, good for large, contiguous reads)
We did a thorough set of benchmarks for some of those situations comparing EBS vs. instance store, namely,
EBS SSD general iops (about 3k for a 1TB volume)
EBS SSD provisioned iops (about 50k for a 1TB volume)
instance store local disk (one disk raid 0)
instance store local disk (two disks striped raid 1)
We had the following takeaways,
the local disk options are vastly better at random access than EBS, due to low latency and iops being a limiting factor. Although most applications try to avoid random reading, it’s hard to avoid completely and so good performance in this area is a big plus.
Sequential reads are also vastly better than EBS, mainly due to rate limiting of EBS, specifically the throughput. Generally you are going to get full, unrestricted access to a local disk with much lower latency than network storage (EBS).
Raid1 is (not surprisingly) up to 2x better for reads than the single disk. Writes are the same due to needing to write to both disks. However on larger system, you can have 4+ disks and do raid10 (mirrored striping) which would give improvements to writes as well.
Unfortunately as mentioned at the start, local disk options are ephemeral and will lose your data on a terminate/stop of the instance. Even so, it might be worth considering a high availability architecture to allow using it.
EBS 50K is certainly more performant than 3K, although you generally need to get past 4+ threads to see a real difference (e.g. a database). Single threaded processes are not going to be much faster (e.g. a file copy, zip, etc..). EBS 50k was limited by the instance max iops (30k), so generally be aware the instance size also can be a limiting factor on EBS performance.
It’s possible to raid EBS as well, but keep in mind it’s networked storage and so that will likely be a real bottleneck on any performance gains. Worth a separate test to compare.
full details on the benchmarks can be found at,
https://www.scalebench.com/blog/index.php/2020/06/03/aws-ebs-vs-aws-instance-storelocal-disk-storage/
Anyone else experienced a sudden network performance cap recently?
Our instances managed to go up to average 100,000,000 bytes average but all of a sudden we're down to 50,000,000 without warning. This happened two days ago at around Oct 16 11:40 UTC.
I'm using a c3.xlarge type instance with network performance moderate, did they lower the cap of the "moderate" performance?
Would be nice to hear if anyone else have this problem since its pretty weird that they would do that without warning, I cant find any information on this.
I've attached screenshot of proof, the instance-type was not changed at that time.
Its the same problem on both Network In and Network Out.
Graph:
http://i.stack.imgur.com/WQ9Sf.png
This is par for the course with shared tenancy. Most instances except for the largest instance sizes, are all on hardware shared with other instances. This means all resources are shared including network bandwidth.
When no other instances are using the bandwidth available to your host, you can generally take advantage of most, if not all of it. If other hosts are attempting to saturate the host bandwidth, then host will schedule your bandwidth based on your network priority.
Moderate does not mean you are guaranteed a certain amount of bandwidth, instead it gives you a certain priority in comparison with the other instances on the host.
What can you do about this? You could stop/start your instance until you get assigned to a host without any noisy neighbors. You could also scale horizontally to give yourself more available bandwidth.
I currently have a quad code single processor dedicated hosting with 4GB of RAM at softlayer. I am contemplating upgrading to a dual processor dual core (or quad core). While doing the price comparison with the reserved large instance in amazon, it seems the price is quite comparable to similar dedicated hosting (maybe ec2 is little cheaper like to like).
Anyone has any other point of view or experience that can shed some more light on this? I want to keep the server running 24 x 7 and my concern is the processor speed (not sure what is amazon's computing unit capabilities) and RAM. For hard disk, I guess I will have to use the elastic storage to avoid loss in case of server breakdown!
If you want to have a server running all the time I usually find the dedicated servers cheaper than cloud ones. In the cloud you pay a bit more for the dynamics that you start and stop server whenever you want.
As for ECU. That is a pity that Amazon does not say how they actually measure it. There is a pretty decent try to measure what it means with multiple benchmarks in this article. But they ended with strongly non-linear scale. Another source tells what ECU is directly proportional to UnixBench - first question on this page. Actually the second link is for service that makes comparison of prices in cloud computing. You may find that Amazon may not necessary have the cheapest CPU. But you should be careful though - the CPU measure is based on the mentioned ECU measurement, which not necessary reflect later actual application performance.
Suppose, I wanted to develop stack overflow website. How do I estimate the amount of commodity hardware required to support this website assuming 1 million requests per day. Are there any case studies that explains the performance improvements possible in this situation?
I know I/O bottleneck is the major bottleneck in most systems. What are the possible options to improve I/O performance? Few of them I know are
caching
replication
You can improve I/O performance in several ways depending upon what you use for your storage setup:
Increase filesystem block size if your app displays good spatial locality in its I/Os or uses large files.
Use RAID 10 (striping + mirroring) for performance + redundancy (disk failure protection).
Use fast disks (Performance Wise: SSD > FC > SATA).
Segregate workloads at different times of day. e.g. Backup during night, normal app I/O during day.
Turn off atime updates in your filesystem.
Cache NFS file handles a.k.a. Haystack (Facebook), if storing data on NFS server.
Combine small files into larger chunks, a.k.a BigTable, HBase.
Avoid very large directories i.e. lots of files in the same directory (instead divide files between different directories in a hierarchy).
Use a clustered storage system (yeah not exactly commodity hardware).
Optimize/design your application for sequential disk accesses whenever possible.
Use memcached. :)
You may want to look at "Lessons Learned" section of StackOverflow Architecture.
check out this handy tool:
http://www.sizinglounge.com/
and another guide from dell:
http://www.dell.com/content/topics/global.aspx/power/en/ps3q01_graham?c=us&l=en&cs=555
if you want your own stackoverflow-like community, you can sign up with StackExchange.
you can read some case studies here:
High Scalability - How Rackspace Now Uses MapReduce and Hadoop to Query Terabytes of Data
http://highscalability.com/how-rackspace-now-uses-mapreduce-and-hadoop-query-terabytes-data
http://www.gear6.com/gear6-downloads?fid=56&dlt=case-study&ls=Veoh-Case-Study
1 million requests per day is 12/second. Stack overflow is small enough that you could (with interesting normalization and compression tricks) fit it entirely in RAM of a 64 GByte Dell PowerEdge 2970. I'm not sure where caching and replication should play a role.
If you have a problem thinking enough about normalization, a PowerEdge R900 with 256GB is available.
If you don't like a single point of failure, you can connect a few of those and just push updates over a socket (preferably on a separate network card). Even a peak load of 12K/second should not be a problem for a main-memory system.
The best way to avoid the I/O bottleneck is to not do I/O (as much as possible). That means a prevayler-like architecture with batched writes (no problem to lose a few seconds of data), basically a log file, and for replication also write them out to a socket.