4 ms·

> But the main point is that you have to really think about how to re-architect your software to take advantage of huge multi-processor machines. I appreciate

> But the main point is that you have to really think about how to re-architect your software to take advantage of huge multi-processor machines. I appreciate the response but it doesn't address my question: given that Let's Encrypt's MySQL-family RDBMS does not implement any of the multi-core/multi-socket/cpu-affinity/lock-free/asyncIO techniques used by databases like ScyllaDB, MemSQL, and VoltDB, why were they seeing 90% CPU utilization on their old Intel servers while the upgraded AMD servers were 25% (the expected range)? I think mike_d's suggestion is most plausible: they probably included custom functions/procedures that invoke CPU-expensive code. I also thought this was a single-node scale-up architecture but since they are using a three-or-more node master/slave architecture, network I/O could somehow be involved.

nijave 6y ago
On "cloud" servers we usually see that when disk I/O stops being the bottleneck (given enough disk I/O you can account for small amounts of RAM). So I'd guess their disk setup had some capacity left when they upgraded or they just have a lot of reads and the data fits in memory
PeterCorless 6y ago
I kind of did answer a different question, but you sort of affirmed my answer & proved my point. If the "expected range" of your CPU utilization is only 25%, then you are knowingly paying for 3x more CPU than you are actually every planning to use. I suppose if you got that cash money and are willing to burn it, nothing I can say will stop you. I just question the logic of it. As for why they suddenly dropped? I'll leave that to someone who knows this particular system far better than I do.
- sradman 6y ago
  I think Jeffbee resolved my confusion; InnoDB uses spin locks that chew up cpu cycles when the request rate exceeds the I/O rate. This is not as bad as it sounds; it uses extra power and generates extra heat but it is not doing any extra real work. InnoDB cores run at either 25% or 90% but the 90% indicates that you need an I/O upgrade not more CPU cycles. Optimizing for CPU efficiency in a system that is I/O bound will not save significant money. Memory and NVMe are the critical factors and with the master/slave replication used, network I/O significantly undercuts the peak performance this single server is capable of.

nijave 6y ago

On "cloud" servers we usually see that when disk I/O stops being the bottleneck (given enough disk I/O you can account for small amounts of RAM). So I'd guess their disk setup had some capacity left when they upgraded or they just have a lot of reads and the data fits in memory

PeterCorless 6y ago

I kind of did answer a different question, but you sort of affirmed my answer & proved my point. If the "expected range" of your CPU utilization is only 25%, then you are knowingly paying for 3x more CPU than you are actually every planning to use. I suppose if you got that cash money and are willing to burn it, nothing I can say will stop you. I just question the logic of it. As for why they suddenly dropped? I'll leave that to someone who knows this particular system far better than I do.

sradman 6y ago
I think Jeffbee resolved my confusion; InnoDB uses spin locks that chew up cpu cycles when the request rate exceeds the I/O rate. This is not as bad as it sounds; it uses extra power and generates extra heat but it is not doing any extra real work. InnoDB cores run at either 25% or 90% but the 90% indicates that you need an I/O upgrade not more CPU cycles. Optimizing for CPU efficiency in a system that is I/O bound will not save significant money. Memory and NVMe are the critical factors and with the master/slave replication used, network I/O significantly undercuts the peak performance this single server is capable of.