如何提升cpu的利用率,怎么解决cpu的利用率

在互联网早期迅速发展时，相关领域企业更多注重于扩展业务，为了迅速占领市场，往往会投入较高的成本。然而，随着互联网人口红利逐渐消退，以及近几年的疫情影响，越来越多企业开始重视成本管理，从“粗放式经营”转变为“精细化运营”模式，成本优化成为企业重点关注事项。

本文将从一位中型企业运维总监的视角来展现一个较完整的成本优化实战案例，希望为读者提供可参考借鉴的成本优化思路。

本文的主人公小王（化名）在某电商公司担任运维总监，他所在公司自建 IDC 机房，其中总共 1000 台业务服务器（在线 离线），由 3 名运维人员管理。机器规格大部分为 8 核 32G，整体 CPU 利用率仅 10% 左右，每年花销在 1000 万以上。

CTO 希望在现有业务市场条件不变的情况下，以业务稳定性为基本前提，将 IT 成本降低至少 30%，且将此定为小王今年的 KPI。

收到任务后，小王先将 IT 成本拆解为算力成本和人力成本两个部分。

目前 IT 成本主要由自建 IDC 机房承载，存在如下问题：

• 自建 IDC 机房机器数量缺乏弹性机制，不便于后期对算力做灵活伸缩；
• 自建 IDC 机房机器进入摊销末期，机型老旧且故障频繁，运维人力成本高。

基于以上分析，考虑到公有云机型更新便捷、基本免维护、可弹性的特点，小王计划先将业务迁移上云。

目前云厂商主要提供了预留实例（包年包月）、按需实例（弹性）、竞价实例三种方式：

• 包年包月：主要针对中长期稳定需求，优点是价格整体比较低，缺点是资源必须长期持有，灵活性差；
• 按需实例：针对短期弹性需求，按秒计费，灵活精准，避免浪费，但价格比较高；
• 竞价实例：以一定幅度的折扣购买，但可能会随时被系统自动回收的实例。价格最低可达到按需实例价格的 10%。由于此类实例随时可能被抢占，所以需要部署的服务应当尽量为无状态服务且有完备的保活和流量调配机制。

为确保系统稳定且尽量减少研发感知，小王先后采取了以下几项措施：

1. 将大部分无状态在线服务和一部分离线服务所在的大概 800 台机器，以包年包月的形式迁移到同等配置的公有云机器上；
2. 腾退相应私有机房机器，并将公有云与私有机房通过专线打通。这样既能保证在线服务上云之后的快速伸缩，又能兼顾数据传输成本及安全方面的考量；
3. 接入公有云相应的部署发布、监控告警、限流自愈等附属功能，从而节省出一个运维的人力。

在上云过程中，小王一方面根据公司需求对比多家公有云厂商后选择最匹配的云资源，另一方面将 CPU 品牌从 Intel 换成 AMD，两者叠加后，降低了 7% 左右的成本。

完成混合云改造后，小王进一步将算力成本拆解为服务算力成本和基础设施资源成本：

• 服务资源指业务服务程序所消耗的 CPU、内存、磁盘、带宽等算力资源，相应成本取决于业务特征、业务运营行为、研发水平等多个因素；
• 基础设施资源成本指大数据、存储、中间件等底层组件和平台的成本。

结合公司目前的成本占比情况，服务算力成本占了其中的 60% 以上。

算力成本来源占比如下图所示：

图 1 算力成本来源占比

基于二八原则，小王决定以运维第三方视角，本着少侵入业务的前提，集中精力节省服务算力成本。

小王首先检查公司已上云的典型业务的算力特征。由于公司业务偏计算型，所以他选择通过常见性能指标 CPU 利用率来观察算力消耗情况，发现公司业务常在中午 12 点左右和晚上 8 点左右迎来算力消耗高峰。

如下图所示：

图 2 CPU 利用率指标算力图

根据上面的业务算力模型，小王发现即使业务完全处于高峰，所需要的机器数也不到现有数量的 80%。在公有云弹性的保证下，小王分阶段释放了历史高峰未触及的 200 多台 8 核 32G 包年包月冗余机器，节省了 20% 左右成本。

在粗略去除明显冗余算力后，小王观察到业务算力即使在忙时利用率也不高，尤其是内存闲置较为严重。

接下来小王和业务一起进行了一次压测，最后得出业务机器规格保持在 8 核 3G 的配比，使用率相对均衡。而公有云机器 CPU 核数和内存配比一般是 1:2 或 1:4 的固定比例，所以小王按照公有云厂商的标准配置先将机器规格从 8 核 32G 降为 8 核 16G，节省了 20% 的成本。

第一阶段的优化手段较为常规，取得了一些效果，小王总共节省了 40% 左右的成本，以较低成本吃到了第一波降本红利。

基于第一阶段的优化经验，小王总结出以下待改进点：

1. 根据 CPU 消耗所衡量出的算力消耗情况和业务的实际情况之间仍有一定差距。比如，经常会出现 CPU 消耗偏高但实际业务依然稳定、无需扩容的情况，这说明需要更加精准的算力度量指标。
2. 业务算力模型明显有波峰波谷，但是资源消耗的模型并未较好匹配，虽去除了未触达的冗余算力，但仍是以最高峰配置全时段占用算力，导致闲时浪费明显。
3. 公有云机器规格中，CPU 与内存的比例有明显限制，导致算力资源使用无法进一步均衡，造成浪费。

基于上述分析，小王分析出需要依次解决的三个问题：

1. 以更精准的业务指标，替代以 CPU 消耗为核心的物理指标；
2. 持续采集该指标，精准匹配算力波动曲线并实时联动扩缩容；
3. 获得更匹配实际业务的机器算力规格，提高资源利用率。

针对以上问题，小王对业界现有解决方案进行了调研，发现并无能直接借鉴的普适方法和经验，大部分实现方式都与特定业务场景绑定且需要研发深度参与。

为了能按期实现目标，小王尝试使用云原生基础治理平台 SchedulX 开始第二阶段的深入优化。

小王借助 SchedulX 系统，在不让业务大规模改造的前提下，引入了 MetricsQPS 指标。该指标将 QPS 中不同请求对机器资源占用的时长纳入了考量，通过对 QPS 按时长进行分段并配以相应的权重最终拟合而成。相对于普通 QPS 指标，MetricsQPS 更能精确地反映出业务实际负载情况。该指标基本计算公式如下：