3 ms·

>c7a servers have dedicated CPUs I can't see any proof of that, sources? They talk about vCPU here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/compu

>c7a servers have dedicated CPUs I can't see any proof of that, sources? They talk about vCPU here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/compute-optimized-instances.html#compute-instances-hardware https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/compute-... Do you mean for example c6g.metal? For c7a there are also "metal" instances available, but they don't mention that: https://docs.aws.amazon.com/ec2/latest/instancetypes/co.html#co_summary https://docs.aws.amazon.com/ec2/latest/instancetypes/co.html...

ndriscoll 3y ago
They're referencing this: > One of the major differences between C7a instances and the previous generations of instances, such as C6a instances, is their vCPU to physical processor core mapping. Every vCPU on a C7a instance is a physical CPU core. This means there is no Simultaneous Multi-Threading (SMT). By contrast, every vCPU on prior generations such as C6a instances is a thread of a CPU core. So your "vCPU" is not an SMT thread sharing a core with some other "vCPU". Of course you're still sharing the rest of the CPU, so things like memory bandwidth and presumably upper level cache, and you might be affected by thermal load from other cores? idk whether that kind of thing applies in server contexts. https://aws.amazon.com/ec2/instance-types/c7a/ https://aws.amazon.com/ec2/instance-types/c7a/
- tlb 3y ago
  It is, however, sharing the memory bandwidth and L3 cache. Which is often a big factor for things like inserting millions of table rows. Benchmarks should be run on an idle bare-metal machine, or you can't really compare results.
  - ndriscoll 3y ago
    Yeah, agree. I had ninja edited that in there but not in time I guess. And as I posted elsewhere, the disk they're using is very slow. And ideally your access patterns are more similar to what the other commenter had with COPY, but that's a whole different issue. AWS will happily sell you bargain bin performance at enterprise prices if you don't understand what you're buying. There's a reason they're almost a $2T company.
  - ardentperf 3y ago
    FWIW, this was why the benchmark was executed on two different servers, and repeated three times on each server. The blog includes a graph of TPS at 5-second intervals for all 24 runs and the results are very tight and consistent. I think that specific graph gives reasonable confidence in the reliability of these numbers.

ndriscoll 3y ago

They're referencing this: > One of the major differences between C7a instances and the previous generations of instances, such as C6a instances, is their vCPU to physical processor core mapping. Every vCPU on a C7a instance is a physical CPU core. This means there is no Simultaneous Multi-Threading (SMT). By contrast, every vCPU on prior generations such as C6a instances is a thread of a CPU core. So your "vCPU" is not an SMT thread sharing a core with some other "vCPU". Of course you're still sharing the rest of the CPU, so things like memory bandwidth and presumably upper level cache, and you might be affected by thermal load from other cores? idk whether that kind of thing applies in server contexts. https://aws.amazon.com/ec2/instance-types/c7a/ https://aws.amazon.com/ec2/instance-types/c7a/

tlb 3y ago
It is, however, sharing the memory bandwidth and L3 cache. Which is often a big factor for things like inserting millions of table rows. Benchmarks should be run on an idle bare-metal machine, or you can't really compare results.
- ndriscoll 3y ago
  Yeah, agree. I had ninja edited that in there but not in time I guess. And as I posted elsewhere, the disk they're using is very slow. And ideally your access patterns are more similar to what the other commenter had with COPY, but that's a whole different issue. AWS will happily sell you bargain bin performance at enterprise prices if you don't understand what you're buying. There's a reason they're almost a $2T company.
- ardentperf 3y ago
  FWIW, this was why the benchmark was executed on two different servers, and repeated three times on each server. The blog includes a graph of TPS at 5-second intervals for all 24 runs and the results are very tight and consistent. I think that specific graph gives reasonable confidence in the reliability of these numbers.