数据库管理-第175期 深入探索CPU性能（20240424）

数据库管理-第175期 深入探索CPU性能（20240424）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
PostgreSQL ACE Partner
国内某科技公司 DBA总监
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家、专家百人团成员，OCM讲师，PolarDB开源社区技术顾问，OceanBase观察团成员
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

在最近的一些观察和交流中，看到了一些很奇怪的东西，比如在不同底层（主要是云上、容器与裸金属等）运行场景下对CPU的利用情况，凸显一些场景对CPU的高效利用。但是在数据库的场景下，到底该关注CPU的哪些指标，CPU在何种运行状态下才是正常的，我有一些不同的看法。

1 CPU的主要性能指标

• 主频（时钟频率）：这是CPU的基本性能指标，表示每秒钟内CPU的时钟周期数，单位通常是GHz。主频越高，CPU的执行速度越快。很多现代CPU在功耗控制的基础上具有一定的单核和全核加速能力，即当前运行功耗未达到最高功耗的情况下，可以根据负载在一定场景下提高单核或全核的CPU运行频率的。
• 核心数量：现代CPU通常具有多个核心，每个核心可以独立执行任务。核心数量越多，CPU能够同时处理的线程数量也就越多，尤其在并行处理任务时。但是核心数量过多可能会出现功耗发热和核心协同的问题。
• 缓存容量：CPU内部的缓存用于临时存储数据和指令，以提高数据访问速度。因为HDD<<<<<SSD<<<MEM<<L3<L2<L1，因此缓存容量越大，可以存储的数据量越多，对于频繁使用的数据和指令，不用频繁的到磁盘甚至是内存中读取，访问速度也越快。
• 指令集：指令集定义了CPU能够执行的操作和支持的指令。不同的指令集可能具有不同的功能和性能优化。
• 指令集架构：在不同指令集架构下（X86、ARM、RISC-V等），软件（指令）的执行方式可能完全不一样。
• 浮点运算性能：浮点运算是涉及小数点的数值计算，如科学计算和图形渲染。浮点运算性能指CPU在处理浮点数运算时的速度和能力。
• 制造工艺：制造工艺是指制造CPU的先进程度，例如使用多少纳米的工艺节点，这影响着CPU的能效和性能。
• …

当然还有电压、功耗、发热/散热比率的等其他指标，这些指标对CPU稳定运行与性能发挥也有一定影响。
上面这些性能指标可以帮助选择性能更好的CPU。

2 CPU的运行状态

在操作系统上有很多指标可以展示CPU的运行状态，以Windows任务管理器为例：

这里面除了CPU基础信息以外，就有利用率、速度（主频）、进程、线程、句柄、正常运行时间等和运行状态相关的内容。而这里的利用率能很好的反映出CPU的运行状态么？我们再看看Linux上的top输出：

这里还是着重关注下CPU相关指标：主要是load average和%Cpu(s)，后者还有很多具体的性能展示指标。而在EMCC对操作系统的监控中又可以看到另外一个指标名称：


既然又多了一个CPU Utilization，是否与前面的某项指标相同呢？那么到底哪些指标能真正展示CPU的运行状态。

2.1 CPU Usage/CPU Utilization

CPU Usage即CPU占用率，就是程序对CPU时间片的占用情况，指在单位时间内CPU处在非空闲态的时间比，反映了CPU的繁忙程度。

CPU Utilization即CPU的占用率，简单来说就是某个时间点上：

CPU占用率=(所有想要获取CPU资源的操作数量-立即获得CPU资源的操作数量)/所有想要获取CPU资源的操作数量*100%

这个性能指标更多的是展示CPU整体的运行情况，对于一般OLTP系统来说，经过实验、实际经验与统计，当CPU占用率到60-65+%的时候，会出出现CPU相关的性能问题，主要源自于等待CPU分配资源的等待，CPU的响应时间上升。

注：这CPU占用了在很多地方的解释和CPU使用率一样的，但是在Oracle RWP培训中则是按照上面内容进行解释的。通过多方面查询以及不同的命令（比如top、sar等）的检索，是有一些不同的，所以这一小节内容请根据实际情况判断。可以把二者一个看做“数字模型”，一个看做“时间模型”。

2.2 CPU Load

load average表示的是CPU的运行负载，包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。这个数字越小越好，一般低于物理核心数量*0.8是合理健康的CPU运行状态。

3 CPU4OLTP

这里我们不讨论OLAP场景，因为OLAP场景下的SQL一般都需要长时间处理，必然长时间占用CPU资源。以“短平快”为主的OLTP场景下，要想SQL跑得快，不仅仅是SQL在CPU上运行时候能起飞，SQL也需要更快甚至是立即能获取到CPU资源。
类比收费站，开车通过最理想的情况是随时都有空闲的通道，而且最好装了ETC，不用停车直接通过。那么如果都装了ETC但是车实在是太多了且不大守规矩，那么在收费站前车与车之间抢道的操作就会造成大堵车，这里就相当于CPU响应时间上升，其实解决方案很简单，让大家守规矩排队通过就好（做好队列）。
那么较低的CPU占用率就一定是CPU资源的浪费么，我不这么认为，合理的CPU占用率反而是更高效使用CPU的表现，每个CPU内核为了快一定是尽可能以最高频率运行的，那么从占用率解释来看，很低的占用率肯定会出现CPU部分核心空闲的状态，但每个核心都在运行时CPU占用率也不应该达到100%，而是在一个大略低于60%的状态。
从业务侧角度来看，特别是重要业务系统且使用集群数据库的情况下，为了确保高可用，即出现部分节点异常的情况下，剩余节点仍然能正常接管业务的角度来看，是需要预留较大量的性能冗余的，因此在一些场景，说在非云环境的CPU资源浪费，也算是一种无稽之谈。还有那些用超分换来的所谓的充分利用CPU资源，在真正急需资源时反而容易出问题。当然动态扩缩容更多的也是事前计划内，事中不一定能顶过异常。

总结

本期半个“外行”探讨了一下CPU相关的一些东西，不一定准确，但针对数据库足矣。
老规矩，知道写了些啥。