4. 虚拟机与虚拟机规模集的性能优化

Azure 虚拟机的性能并不是单一参数决定的,而是由计算规格、磁盘子系统、网络路径、物理部署位置以及规模集的伸缩策略共同作用的结果。很多生产事故的根因并非应用代码,而是选型与配置之间的错配:用 B 系列突发实例承载持续高负载、把高 IOPS 数据库放在 Standard HDD 上、跨区域部署导致节点间延迟抖动、自动缩放规则只看 CPU 而忽略队列深度。本节围绕这些真实问题,梳理从选型到调优的完整判断链路。

VM 大小选型:先看约束,再看性价比

选型的第一步不是比较价格,而是识别工作负载的硬约束。内存密集型(如 Redis、SAP HANA)应优先看 E 系列或 M 系列;计算密集型(如视频编码、批处理)看 F 系列;通用型 D 系列适合大多数 Web 与中间件;B 系列仅适合平均利用率低、允许积分耗尽后降速的场景。GPU 训练则必须落到 NC/ND/NV 系列,并注意 vCPU 与 GPU 配比。

一个常被忽略的细节是:同一系列中带 s 后缀(如 D4s_v5)的规格通常支持 Premium SSD,而不带 s 的旧规格可能只支持 Standard SSD。若磁盘 IOPS 是瓶颈,选错后缀会直接导致无法挂载 Premium 磁盘。此外,v5 相比 v3 在相同 vCPU 下通常有更高的内存带宽和网络吞吐,迁移到新代际往往比纵向扩容更划算。

选型检查顺序建议:内存容量 → vCPU 与内存比 → 是否支持 Premium SSD → 网络带宽与加速网络 → 区域可用性 → 价格。前四项是硬约束,后两项才是优化空间。

磁盘类型与缓存策略

Azure 托管磁盘分为 Standard HDD、Standard SSD、Premium SSD、Premium SSD v2 和 Ultra Disk。性能与成本大致递增。生产数据库的日志盘应使用 Premium SSD 或 Ultra Disk,因为写入延迟直接影响事务提交;数据盘可用 Premium SSD v2 按需调整 IOPS 与吞吐,避免为峰值过度配置容量。

缓存策略是磁盘性能中最容易配错的一项。主机缓存有三种:None、ReadOnly、ReadWrite。判断依据是数据一致性要求:

  • 只读或读多写少的数据盘:ReadOnly,可显著提升读 IOPS。
  • 数据库数据文件:通常 ReadOnly,但若应用自行保证一致性也可用 None。
  • 数据库日志文件:必须 None,因为日志要求持久化写入,缓存会破坏崩溃恢复语义。
  • 临时盘:默认 ReadWrite,但临时盘数据不持久,不可存放需保留的数据。

下面这张图展示了从工作负载特征到磁盘与缓存决策的判断路径,以及缓存策略对读写路径的影响。

磁盘类型与缓存策略决策路径 工作负载特征 读写比 / 延迟要求 是否要求持久化写入 日志 / 事务提交 缓存 = None 缓存 = ReadOnly IOPS / 吞吐需求 峰值 vs 平均 Premium SSD v2 Ultra Disk Standard SSD 缓存策略对读写路径的影响 应用写入 主机缓存层 托管磁盘 存储后端 None:写入直达磁盘,保证持久化,适合日志 ReadOnly:读命中缓存,写穿透,适合数据文件

加速网络与邻近放置组

加速网络(Accelerated Networking)通过 SR-IOV 将网络数据路径从虚拟交换机卸载到网卡,可显著降低延迟、减少 CPU 占用。对延迟敏感的服务(如微服务间调用、数据库复制、Kafka 集群)应开启。开启条件:VM 规格支持、操作系统支持、且需在创建时或停机后启用。多数 D/E/F 系列 v3 及以上默认支持。

邻近放置组(Proximity Placement Group, PPG)用于将同一组 VM 尽量部署在同一数据中心内,降低节点间网络延迟。它适合有强节点间通信的集群,如 SAP、HPC、Redis 集群。代价是:PPG 内的 VM 在扩容时可能因容量不足而失败,且 PPG 与可用性区域不能同时使用。因此,PPG 应只用于真正需要低延迟的层,而不是整个规模集。

自动缩放规则与成本权衡

虚拟机规模集的自动缩放规则由“指标 + 阈值 + 时间窗口 + 动作”组成。常见错误是只用 CPU 百分比:对于队列型服务,CPU 可能不高但请求排队严重。更稳妥的做法是组合指标,例如 CPU 平均 > 70% 持续 10 分钟扩容,< 30% 持续 15 分钟缩容,同时设置最小/最大实例数防止震荡。

成本权衡的核心是:扩容快、缩容慢。扩容要迅速响应流量,缩容要保守避免抖动。可以设置冷却时间(默认 5 分钟)和实例数上下限。对于可预测的流量,使用计划缩放(按时间表)比纯指标缩放更省钱。

生产环境实战调优案例

某订单服务部署在 4 台 D4s_v3 规模集上,使用 Standard SSD 数据盘,缓存为 ReadWrite,未开启加速网络。高峰期 P99 延迟从 80ms 升至 600ms,CPU 仅 55%。排查发现:磁盘写入延迟高、缓存策略错误导致日志写入被缓存、网络重传增加。

调优动作:将日志盘改为 Premium SSD 并设缓存 None;数据盘改 Premium SSD v2 并设 ReadOnly;开启加速网络;将规模集改为 D4s_v5;自动缩放改为 CPU>65% 扩容、<35% 缩容,最小 4 最大 12。调整后高峰期 P99 降至 120ms,CPU 利用率升至 70% 但更平稳,月度成本因 v5 性价比提升和缩容策略反而下降约 8%。

调优顺序建议:先修正缓存策略和磁盘类型(影响最大且成本可控),再开启加速网络,最后调整规格与缩放规则。每次只改一项并观察 24 小时,避免多变量同时变化导致无法归因。

总结来看,VM 与规模集的性能优化是一条从硬约束到软策略的链路:选型决定上限,磁盘与缓存决定 IO 表现,网络与放置决定延迟,缩放规则决定成本弹性。生产调优应基于指标而非直觉,逐项验证,才能同时获得性能与成本的平衡。