3 ms·
> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed
by gpm 4y ago
> since those tend to run at a sustained max anyway
Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.
- staindk 4y agoI think this means you were paying for the over-provisioning i.e. paying for a full CPU or baremetal server? "The Cloud" is all about vCPU - "2 vCPUs" feels somewhat standard for a base-tier VPS... and 2 vCPUs means "2 virtual CPUs" or rather "roughly equivalent to 2 CPU cores" I think. I understand that jargon to mean they are always cramming 11 x 2vCPU clients onto 20 physical cores.
- ceeplusplus 4y agoNo, 2 vCPUs is 2 logical threads, which is equivalent to a single physical core on x86. So yeah, they are cramming 11 x 2 vCPUs onto 20 physical cores. In fact, it's more like 20 x 2 vCPUs.
- sofixa 4y agoDepends on the cloud - OVH and Digital Ocean yes, but AWS give you whole uncontested cores ( bar the t* instance line, but that's it's whole thing).
- phamilton 4y agoNah, vCPU is generally just hyperthreading. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html#cpu-options-compute-optimized https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-opti... So you get 2 vCPUs per core.
- staindk 4y agoThanks for the link, that's great to know about AWS. I don't think all other VPS providers are that good about things - googling around for some other definitions of vCPU (in VPS context) I see a lot of examples of 16 thread server CPUs handling "128 vCPUs".
- sofixa 4y agoDepends on your workload, spot batch jobs would run at sustained maximum.
- gpm 4y agoAbsolutely, my observation is in a way that "most workloads don't seem (to me) to be like that". The number of servers serving interactive queries (frontends, rest api servers, databases, etc) seems (to me) to greatly outnumber the number of batch jobs, and I've always seen those intentionally "over" provisioning CPU because otherwise you get latency issues if load increases at all. I don't actually know that cloud providers don't either have some clever way around this (e.g. spending spare CPU cycles on some other form of work), or that it isn't the typical usage pattern, but I strongly suspect it.
- rhn_mk1 4y agoThat only means you were making space for others to phase in and use the remaining resources that you spared. You're not the one deciding which process sits on which resource, after all. The only reason why resources might be left unused are usage spikes that all customers share.
- bombcar 4y agoDynamic scaling involves bringing the CPU frequency down but not off - you can get almost as much power savings for some loads by using the old HLT instruction, so your CPU/core is either at full speed or basically off.
- depereo 4y agoI am on the cloud provider side; we would sometimes limit the upper and lower range of frequency but completely disabling scaling would be very unusual.
- href 4y agoSame. Our compute hosts are generally not using 100% of their cores at all time. There’s computes that are not full, computes that run rather diverse tenants, and even the fully utilized computes responsible for CPU optimized VMs have enough variance in their workload for frequency scaling to occur.