Whats is burstable instance in GCP? Does it mean , that instance can be automatically deleted if other devices need quota? Is it same as preemptive instance?
Shared-core machine types offer bursting capabilities that allow instances to use additional physical CPU for short periods of time. Bursting happens automatically when your instance requires more physical CPU than originally allocated. During these spikes, your instance will opportunistically take advantage of available physical CPU in bursts. Note that bursts are not permanent and are only possible periodically. Bursting doesn't incur any additional charges. You are charged the listed on-demand price for f1-micro, g1-small, and e2 shared-core machine types.
See also:
CPU bursting
Related
I have create a AWS EC2 instance to run a computation routine that works for most cases, however every now and then I get an user that needs to run a computation routine that crashes my program due to lack of RAM.
Is it possible to scale the EC2 instance's RAM and or vCPUs if required or if certain threshold (say when 80% of RAM is used) is reached. What I'm trying to avoid is keeping and unnecessary large instance and only scale resources when needed.
It is not possible to adjust the amount of vCPUs or RAM on an Amazon EC2 instance.
Instead, you must:
Stop the instance
Change the Instance Type
Start the instance
The virtual machine will be provisioned on a different 'host' computer that has the correct resources matched to the Instance Type.
A common approach is to scale the Quantity of instances to handle the workload. This is known as horizontal scaling and works well where work can be distributed amongst multiple computers rather than making a single computer 'bigger' (which is 'Vertical Scaling').
The only exception to the above is when using Burstable performance instances - Amazon Elastic Compute Cloud, which are capable of providing high amounts of CPU but only for limited periods. This is great when you have bursty needs (eg hourly processing or spiky workloads) but should not be used when there is a need for consistent high workloads.
I deployed the Machine Learning classification model in AWS EC2 (UBUNTU)instance successfully. I am able to access the instance "http://ec2-18-191-31-0.us-east-2.compute.amazonaws.com" and predictions are working fine only for few minutes. After that I or my colleagues are not able to access this. Getting an error "cannot connected to the server".
Security group that I crated as attached.
t2.micro instances are not suitable for any long running calculations. They are burstable. This means that their performance can be sustained only for short periods of time, e.g., sudden, short lived spikes in CPU usage. On top of that they have only 1 GB of RAM which limits its usefulness in machine learning.
For calculations, you could consider Compute optimized or Memory optimized instances. Obviously, these instance types are not free, but they are suited for calculations.
You can change instance type if you want and test with other, more power types. What you are describing indicates that your t2.micro exhausts all its RAM and/or CPU burst credits after few minutes and it freezes.
You can use CloudWatch Metrics for EC2 to monitor your instances and observer its CPU utilization and other metrics which can help you determine what exactly is causing the backlog. You can also monitor RAM and disc usage but this requires CloudWatch Agent setup on the instance.
I'm planning to deploy a production environment in the AWS cloud. I'm not sure about which instance type do I choose as my servers. When I did some R&D on choosing instances types, I came to know about Fixed performance instances like (m4, m5, etc) and Burstable instances like (t2, t3, etc). I doubt I can't go with Burstable instances as we are planning to go live/production. Later I came to know about Unlimited mode in Burstable instances.
So my main doubt is If I go with Burstable mode along with unlimited mode, it will work exactly like fixed performance, right? So, any time there is a spike in compute, this mode will burst to the required performance because of unlimited mode.
Is that similar to fixed performance? What is the difference?
The main difference is the cost. If your t2/t3 instances stay within their accrued CPU credits then they will cost much less than the fixed performance m4/m5 instances. As long as they stay within that CPU usage limit and only go into Unlimited CPU mode rarely and for very short periods of time, then they will save you money. If they end up using Unlimited CPU mode a lot then they may end up costing more than the m4/m5 instances at which point you might as well use the fixed performance versions.
AWS EC2 T3 instances offer a balance of compute, memory, and network resources, and are designed to provide a baseline level of CPU performance with the ability to burst above that baseline when needed.
That being said , if you feel your application not CPU intensive and its doesn't usually crosses baseline its good to choose t3 to save the cost. (t3 are cheaper then t2's for linux)
CPU Credit balance on my AWS EC2 server dropped to zero and now my system is very slow.
What can I do to fix this?
I use t2.micro EC2 instance.
For how long it will be zero? To the end of month, forever?
The credits will only come back if you reduce your CPU load. You can enable T2 Unlimited to avoid the limitation, but please note that extra costs will likely apply.
If you are frequently running out of Credits, you should consider using a larger instance type (eg t2.small, t2.medium) or a different instance family. T2/T3 instances are good for workloads that occasionally burst, but is not ideal for sustained workloads.
See: CPU Credits and Baseline Performance for Burstable Performance Instances
We are considering upgrading from an t2.micro AWS server instance to a m3.medium instance based on the recommendation here and some research offline. We feel the need to upgrade primarily for speed issues and to ensure google bots crawl our fast growing site fast enough. We have upward of 8000 products (on magento) and that will grow.
While trying to understand what exactly could be the constraint of the current t2.micro instance, we ran through a lot of logs but couldn't find anything specific that could indicate a bottle-neck as such in the current usage.
Could anyone help point out
1. What are the clues that can be found in logs which could show potential bottleneck issues(if-any) with the current t2.micro instance
2. How could we find out if google-bot had issues while crawling and stopped crawling due to server performance related issues.
There are two things to note about t2.micro instances:
They have CPU limitations based upon a CPU credits system
They have limited network bandwidth
CPU credits
The T2 family is very powerful (see comparison between t2.medium and m3.medium), but there is a limit on the amount of CPU that can be used.
From the T2 documentation:
Each T2 instance starts with a healthy initial CPU credit balance and then continuously (at a millisecond-level resolution) receives a set rate of CPU credits per hour, depending on instance size. The accounting process for whether credits are accumulated or spent also happens at a millisecond-level resolution, so you don't have to worry about overspending CPU credits; a short burst of CPU takes a small fraction of a CPU credit.
Therefore, you should look at the CloudWatch CPUCreditBalance metric for the instance to determine whether it has consumed all available credits. If so, then the CPU will be limited to 10% of the time and you either need a larger T2 instance, or you should move away from the T2 family.
In general, T2 instances are great for bursty workloads, where the CPU only spikes at certain times. It is not good for sustained workloads.
Network Bandwidth
Each Amazon EC2 instance type has a limited amount of network bandwidth. This is done to prevent noisy neighbour situations. While AWS only describes bandwidth as Low/Moderate/High, there are some better details at: EC2 Instance Types's EXACT Network Performance?
You can monitor network traffic of your EC2 instances using CloudWatch. Pay attention to NetworkIn and NetworkOut to determine whether the instances are hitting limits.