I wonder when we will get instances that can scale dynamically at runtime!

That would be so cool, just adding cores if the load goes up!

You would have to make sure your code has enough threads ready to fill those cores though! (if you use non-blocking async. stuff)

Or is this what they mean it already has?

Edit: thinking more about this it must be really hard and require kernel fixes?

I mean how would linux behave when you add/remove cores and RAM f.ex.?

It’s a lot easier and safer to scale hosts horizontally than vertically. You can predict the limits and behavior of each host, the VMs/processes on each host don’t need to deal with fundamental resources changing, etc. For services I own that are high availability, require GC tuning, etc., these hosts with dynamic resource adjustments (also T2/T3 in AWS) are a nightmare because the behavior can change at runtime under load, exactly when I want it to behave predictably.

Sure but:

1) Some things can't scale on more hosts, like say an action MMO with no sharding.

2) Scaling dynamically does not necessarily mean you have to do it unpredictably.

Are you running them as unlimited or standard?

Oh definitely there are valid use cases for these, was just sharing my experience with them for my use cases.

We moved off of T2’s and back to C’s because of the unpredictable behavior under load. IIUC, T3s by default just bill you more instead of CPU throttling, which is a bit better for our use cases, but we haven’t tried them yet.

Aha, thanks for that very valuable information!

T3 look cheaper and better than E2 then, my only problem is region placement where Iowa and Taiwan are more central than anything AWS offers (still no central US region!?).

I'm in the MMO business, so very specific requirements.

Disclosure: I work on Google Cloud.

T3 is pretty different (even in unlimited mode) than E2. As an example, t3.xlarge (4 vCPU, 16 GB, $.167/hr, so $.042/hr/vCPU roughly) only has a baseline performance of 40% (so 1.6 vCPU). If you cross that threshold in unlimited mode you pay an additional $.05/vCPU/hr (so more than doubling your cost). By comparison an e2-standard-4 is $.134/hour even if you run it flat out.

We take on the statistical multiplexing over the datacenter and move VMs around, instead of pushing it to you as an economic or performance-throttling risk when you need it most. If you want a burstable type, we do have an e2-{micro, small, medium} that only guarantees you 12.5%, 25% and 50% of your 2 guest-visible vCPUs. But that's more fit for dev workstations and so on.

Are the shared E2 cores (e1-micro f.ex.) guaranteed to be on different physical cores? See my reply to AWS below.

> We take on the statistical multiplexing over the datacenter and move VMs around

You're implying here that EC2 doesn't do this.

On what basis?

Sorry if I was unclear. In unlimited mode, if you sustain greater than your baseline percentage, you pay for it (the key point of the sentence you’re quoting is that we take on the risk). One reason for this happens to be because AWS doesn’t do migration (yet?), but instead does an awesome job of doing in-place upgrades (see their talks on Nitro, for example).

Disclosure: I work for AWS.

We have many tools in our toolbox at our disposal: non-disruptive in-service updates moves live migration from a "must have to operate compute cloud service at all" to "helpful in some scenarios when the workload and/or situation warrants the impact to performance during precopy / potential post-copy phases."

But I would not assume that EC2 does not have that particular tool in the "fully production, and used" toolbox.

I have my doubts, in the past I've received decom-notifications that EC2 was going to be shutting down my instances in the near future due to underlying hardware failure (very helpful, since I was in the middle of triaging why the instance was behaving strangely). Seems like a poor customer experience to reap running instances if live migration is on the table.

Are the T3 cores guaranteed to be on different physical cores?

When are you building a central US region?

Disclosure: I work for AWS

T3 instances provide hyperthreadded vCPUs to EC2 instances, and the Nitro Hypervisor uses a core based scheduler (coscheduler) to ensure that cores are never shared between two EC2 instances.

Upstream Linux kernel changes that are based on some of the changes in the Nitro Hypervisor were posted to lkml in 2018: https://lwn.net/Articles/764482/

I hope to see the GCE team contributing more to the ongoing discussion on core based scheduling!

That doesn't really answer my question, if I have a t3-micro (which cores do not fill an entire physical core, so they are shared with others) am I guaranteed both of the cores for the instance are running on separate physical cores so that my two cores don't share one physical core?

This in order to allow for my server to continue operation if the steal rate of one core goes through the roof because some other instances running on my shared physical core are taking too many resources unexpectedly.

And how does Amazon explain still not having a central region in the US? I mean the multiplayer share of your revenues must be at least 10% by now?

I just managed to get a IONOS instance running in Kansas City (same distance from east/west-coasts) for low-and-behold 1€/month with unlimited data (18GB SSD and 512MB RAM). How is AWS going to compete with that?

A t3.micro has two vCPUs, where each vCPU is backed by a hyperthread of a physical core. Because the scheduler used by the Nitro Hypervisor core based scheduling (see [1]), the two vCPUs will always map to the two threads of a physical core. You will not run on two separate physical cores are the same time if you have only 2 vCPUs allocated to your T3 instance.

The scheduler can move where your vCPUs run based on available resources.

I can try to explain virtual machine CPU scheduling, but I can't explain when or where AWS will build new regions that have not been announced. :-)

[1] https://lwn.net/ml/linux-kernel/20180907214047.26914-1-jscho...

Are the E2 cores guaranteed to be on different physical cores?

Every search result I can see says that EC2 doesn't do live migration. You can try to balance things but you can only do so much if you can only move a VM when it happens to reboot by itself. (And there's no evidence I can find that they even do that.)

Disclosure: I work for AWS on EC2

EC2 instances that have no local storage state can move between hosts in response to events like reboots.

CPU hotplug has been supported for a long time. I once managed some Sun boxes that allowed replacing/upgrading CPUs without shutting down... They don't build em like that anymore.

Disclosure: I work on Google Cloud.

Yes, but most workloads are fairly unprepared for this sadly. And they're really not ready for memory unplug. (I also miss the days of my multi socket boxes and plugging in CPUs and memory).

> And they're really not ready for memory unplug.

What do VM-guest memory-ballon drivers do right now when the host suddenly attempts to reserve more memory than the guest has free? I'd presume the kernel would just consider itself to be in an OOM condition, and start killing processes to free up the memory until it can return OK to the balloon driver, no?

Because, from what I understand, that's closer to the scenario we're talking about here: you're not abruptly yanking DIMMs (like physical memory hotplug); rather, you (the hypervisor) are gracefully letting the guest know that some memory is about to go away, and since you (the hypervisor) have your own virtual TLB, you can let the guest OS decide which "physical" memory (from its perspective) is going away, before it happens.

Yep! I was just responding to the explicit "how come you don't do hotplug" :).

Linux and Windows have both supported it, but use tends to be at the fringes on mainframe/datacenter machines that are validated for it and so those paths aren't tested on a very wide variety of hardware and running applications. And adding CPUs and memory is one thing but removing is another.

CPU cores being hotplugged on & off was actually super common for a few years, and still is in a lot more devices than you'd expect.

It used to be a corner stone of power management on mobile devices. The Nexus 5, for example, would regularly run with just a single core online, hotplugging the other 3 off until hit with a load and then brought cores back online 1 by 1 as needed.

That behavior still is in some corners of the mobile world, but increasingly less so.

So the CPU hotplug path is as a result actually a lot more battle hardened than you'd expect, and a lot more consumer software than you'd think ran just fine in that setup without noticing.

It's been supported with VmWare for a while too, maybe a whole decade.

> I mean how would linux behave when you add/remove cores and RAM f.ex.?

This is already possible on ESXi with Linux guests for years now, so it’s certainly a solved problem in some capacity.

> This is already possible on ESXi with Linux guests for years now, so it’s certainly a solved problem in some capacity.

And has been possible on KVM (e.g. VirtManager, RHV/RHEV/Ovirt) for years too.

Xen 3 also supported online memory increases (but I don't think CPU).

I presume that this means that E2 instances won't have access to local scratch NVMe, since making use of local scratch NVMe disks currently prevents any feature that requires a live migration, like auto-migration on host maintenance, or modifying the VM's specs while stopped (as you can't stop VMs with local storage, only terminate them permanently.)

You can still get migrated with a local ssd:

"Compute Engine can also live migrate instances with local SSDs attached, moving the VMs along with their local SSD to a new machine in advance of any planned maintenance." [1]

[1] https://cloud.google.com/compute/docs/instances/live-migrati...