第10章云计算性能

虚拟化、容器与云原生

章节导读

云改变了性能分析的游戏规则。传统数据中心里，你拥有一台确定的机器：CPU 型号已知、内存独享、磁盘直连，性能问题一定在你能看到的层次里。云上，你的"机器"是一层抽象：vCPU 是宿主机调度的一个线程，内存可能被超售，磁盘是网络另一端的分布式存储集群，网络经过虚拟交换机与 overlay 封装——更麻烦的是，你的邻居（其他租户）的行为会通过共享的物理资源影响你，而你看不见他们。Gregg 在 AWS 工作多年后为第 2 版新增的这一章，核心信息是：云性能分析 = 传统全栈分析 + 虚拟化层分析 + 云平台配额/限流分析，三者缺一不可。

先理解虚拟化的性能税。全虚拟化到硬件辅助虚拟化的演进：早期软件模拟（QEMU TCG，每条指令翻译，慢 10-100 倍）→ 半虚拟化（Xen PV，guest 内核改造成 hypercall 接口，I/O 性能可用）→ 硬件辅助（Intel VT-x/AMD-V：CPU 增加 root/non-root 模式，guest 内核直接跑在物理 CPU 上，特权操作触发 VM exit 陷入 Hypervisor）。VM exit 是虚拟化开销的核心：每次 I/O 端口访问、某些指令（CPUID、HLT）、中断注入、EPT violation（扩展页表缺页）都触发 exit-enter 循环，每次约 1-2μs。优化技术：virtio 半虚拟化 I/O（guest 与 host 通过共享内存环通信，批量提交减少 exit）、vhost-net（网络数据面卸载到宿主机内核）、SR-IOV（网卡硬件虚拟化，VF 直通 guest，接近物理性能）、EPT/大页（减少内存虚拟化开销）。典型开销数字（现代 KVM + virtio）：CPU 计算 <2%（纯用户态代码几乎无 exit）、内存 2-5%（EPT 两级页表遍历，guest 大页可缓解）、网络 5-15%（每包处理路径长，SR-IOV 可降到 <5%）、磁盘 5-20%（virtio-blk 一层转发，NVMe 直通或 vhost-user 更优）。

噪声邻居（noisy neighbor）是多租户的本质问题。共享资源清单：物理 CPU（超售：宿主把 96 核卖成 192 vCPU，高峰时你的 vCPU 排队等物理核——guest 内表现为 %steal）、LLC（L3 缓存被邻居的数据冲刷——你的缓存命中率莫名下降，Intel RDT/CAT 可隔离但云厂商未必启用）、内存带宽（邻居跑内存密集负载，你的访存延迟上升——最难观测的干扰，guest 内几乎无指标）、磁盘后端（共享存储集群的 IOPS/带宽被其他租户占用）、网络（物理网卡与 TOR 交换机上行带宽共享）。诊断方法：%steal 是 CPU 争抢的直接指标（mpstat，持续 >5% 即显著）；缓存与内存带宽干扰表现为"IPC 下降但代码没变"（perf stat 对比历史基线）；平台侧指标（云厂商的 host-level metrics，部分企业级实例提供）是最终证据。缓解手段：独占型实例（dedicated host/tenancy，物理机独享）、更大规格（大实例在宿主机上占比大，受干扰概率与程度都低）、避开高峰购买（超售在高峰才显性）、应用层冗余（多副本跨 AZ，单实例抖动被负载均衡吸收）。方法论调整：云上的性能回归先问"是代码变了还是环境变了"——同版本代码性能漂移 10-20% 很可能是邻居或宿主机迁移（live migration 会造成秒级停顿与之后的缓存冷启动）。

容器：共享内核的轻量隔离。namespace 提供视图隔离（PID、网络、挂载、UTS、IPC、user），cgroups 提供资源限制与计量。性能要点：（1）容器不是虚拟机——没有虚拟化层，CPU/内存访问接近原生（<1% 开销），开销集中在特定路径：overlayfs 的 CoW（容器内写镜像层文件触发 copy-up：首次写延迟 + 空间翻倍，数据与日志必须挂 volume）、网络 namespace 的 veth 对（每包多两次协议栈穿越，约 5-15% CPU 税，host 网络模式可消除但失去隔离）、cgroup 记账本身（每进程每调度事件的记账开销，cgroup 数量巨大时（K8s 每 Pod 多层 cgroup）内核开销显著——cgroup v2 与统一层级改善了这点）。（2）CPU 限流（CFS bandwidth control）：cpu.max = "配额周期"（如 "200000 100000" = 2 核），周期内用完配额即冻结（throttle）到周期结束——应用表现为规律性 100ms 级延迟毛刺，即使平均 CPU 利用率只有 50%（突发并行度超过配额的瞬时速率）；观测：cpu.stat 的 nr_throttled/throttled_usec，guest 内 runqlat 的规律长尾；解法：加配额、降线程数（匹配配额核数）、或改用 cpu.weight（份额制，不限流——K8s 的 requests 语义）。（3）内存限制：超限触发 memcg OOM Kill（exit 137），限制含页缓存；memory.high（v2）提供软限流缓冲带（超过后激进回收 + 分配减速，而非直接杀）。（4）容器内的观测失真：/proc/cpuinfo 与 /proc/meminfo 显示宿主机资源（procfs 不是 namespace 化的！）——JVM/Go/线程池按宿主机核数配置是经典事故（Java 10+ 与 Go 1.19+ 才正确感知 cgroup 配额），free/top 的数字在容器内不可信，要读 cgroup 文件（/sys/fs/cgroup/memory.current、cpu.stat）。

Kubernetes 的性能维度。调度延迟：Pod 从创建到绑定节点（scheduler 吞吐约每秒数百 Pod，大规模集群的调度延迟与抢占行为要观测 scheduler_e2e_scheduling_duration 指标）；镜像拉取（冷启动的大头：GB 级镜像拉取分钟级——镜像瘦身、预热（DaemonSet 预拉）、P2P 分发（Dragonfly）、按需加载（Nydus/eStargz、 SOCI snapshotter）是启动优化的主战场）。Pod 启动时间全链路：调度 + 镜像拉取 + 容器创建 + 应用启动 + 就绪探针通过——逐段观测（kubelet 日志、Pod events、应用启动日志）才能优化正确的段。网络插件（CNI）：overlay（VXLAN：封装税 + MTU 减小）、路由（Calico BGP：接近原生）、eBPF（Cilium：绕过 iptables/kube-proxy，大集群必选——iptables 模式的规则同步在 5000+ Service 时是分钟级，新 Pod 上线后长时间连不通旧规则）。kube-proxy 与 Service：ClusterIP 的 DNAT 税（每包规则匹配）、conntrack 表（每连接一条，表满丢包——高并发集群调 nf_conntrack_max 与 buckets）。资源管理：requests/limits 的语义（requests 是调度依据与 cpu.weight 份额，limits 是硬上限——CPU limit 触发 throttle，内存 limit 触发 OOM Kill；"只设 requests 不设 CPU limit"是延迟敏感服务的常见建议，避免 throttle 毛刺）。QoS 等级（Guaranteed/Burstable/BestEffort）决定驱逐顺序与 NUMA/CPU 独占资格（Topology Manager 只对 Guaranteed 生效）。

云存储与云网络的性能模型。云盘（EBS 类）：性能 = f(容量, 档位)——gp3 基线 3000 IOPS/125MB/s 与容量解耦（可独立加购到 16K IOPS），gp2/io2 按容量线性（gp2：3 IOPS/GB，1TB 盘 3000 IOPS——小盘性能陷阱：100GB 盘只有 300 IOPS！）；突发额度（burst balance）耗尽后跌回基线（开发环境"平时很快压测变慢"的常见原因）；延迟构成：guest 栈 + virtio + 宿主机 + 网络 + 分布式存储后端（3 副本写），典型 100-500μs（比本地 NVMe 高一个数量级）；观测：guest 内 biolatency + 平台指标（VolumeQueueLength——宿主机侧排队，guest 看不到；EBS 的 volume 级 CloudWatch 指标）。对象存储（S3）：首字节 10-100ms（GET），单前缀 3500 PUT/5500 GET 每秒的扩展上限（前缀分区——key 设计要散列前缀）， multipart 上传与 Range GET 并行化是大文件的标准姿势。云网络：实例带宽/pps 按规格档位、突发与基线（小规格实例的"网络性能"可能只有 1Gbps/10 万 pps）；跨 AZ 1-2ms 与跨 AZ 流量费；LB 的 idle timeout 与连接排空；NAT 网关的端口与带宽限制。

云环境性能方法论的调整（本章的落脚点）：（1）先查平台配额与限流——云上一半的"性能问题"是撞了某个看不见的上限（实例网络 pps、云盘 IOPS、Lambda 并发、API 速率限制），平台指标与配额页面是第一站；（2）%steal 与宿主机指标纳入常规检查——CPU 争抢、live migration 事件（云平台的事件日志）；（3）容器内观测要用 cgroup 口径——/proc 的宿主机视图会误导一切自动配置；（4）弹性伸缩的性能语义——扩容不是瞬时的（镜像拉取 + 应用预热 + JIT 编译，Java 服务新实例前 2 分钟性能只有稳态一半——预热流量与 readiness 探针配合）、缩容要排空（connection draining）；（5）分布式追踪是云原生排障的入口——单实例分析之前先定位"哪个服务哪一跳慢"（OpenTelemetry + 黄金信号）；（6）成本与性能的联合优化——云上性能优化的收益直接货币化（同样的 SLO 下减少实例数/降规格/换存储档位），FinOps 视角让性能工作有了 ROI 语言。

核心概念

虚拟化
噪声邻居
cgroups
Kubernetes
云盘

要点精析

%steal time 的机制与判读。steal 是 Hypervisor 从你的 vCPU"偷走"的时间：vCPU 线程在宿主机上处于 runnable 但没拿到物理核（宿主机调度器在跑别的 vCPU），guest 内核通过 steal time 接口（PV 时钟）得知这段被偷的时间并计入 %steal。判读：持续 <2% 正常（宿主机轻度超售）；5-20% 显著争抢（性能与延迟直接受损，突发型实例额度耗尽也表现为 steal）；>20% 严重（考虑换实例类型/规格/可用区，或向云商申诉——企业级支持通道对持续 steal 有 SLA 语义）。steal 的隐蔽形态：它只统计"整段被偷"的时间，LLC 与内存带宽干扰不计入 steal（表现为 IPC 下降而非 steal 上升）；live migration 期间 steal 尖峰 + 之后的缓存冷启动（性能恢复需要分钟级预热）。相关指标：guest 内 mpstat %steal、/proc/stat 的 steal 列、云平台的 CPU credit balance（突发型实例）与 host-level 指标。方法论：云实例的性能基线漂移分析，steal 时序是第一个要叠加的曲线。

CPU 限流（CFS throttling）的完整机制与对策。cpu.max="200000 100000" 表示每 100ms 周期最多用 200ms CPU 时间（2 核等效）。限流的微观行为：周期内配额耗尽 → 该 cgroup 所有任务被冻结（dequeue）→ 周期边界统一解冻——即使应用只需要"平均 1.5 核但瞬时 4 核并行 50ms"，也会触发冻结：4 核 × 50ms = 200ms 配额瞬间用完，剩余 50ms 全体冻结，请求延迟 +50ms 毛刺。这就是"平均利用率 50% 却有限流毛刺"的机制（并行度 × 时间才是配额的消耗口径）。观测：cpu.stat 的 nr_periods/nr_throttled/throttled_usec（限流周期占比 >5% 即显著）；runqlat 显示与 100ms 周期对齐的长尾；应用延迟直方图出现 ~100ms 间隔的规律毛刺。对策：（1）加配额（limits 提到峰值并行需求）；（2）降并行度（线程池/GOMAXPROCS 匹配配额核数——Go 的 automaxprocs、Java 的 ActiveProcessorCount）；（3）去掉 CPU limit 只留 requests（份额调度不限流，K8s 延迟敏感服务的常见选择，代价是节点超售时靠 weight 竞争）；（4）内核侧：CFS bandwidth 的 burst 特性（5.14+，cpu.max.burst 允许积累未用配额应对突发）与 cgroup v2 的更平滑实现。

容器内存限制的语义与 OOM 防线。memcg 的 memory.current 计入：匿名页（堆栈）+ 页缓存（该 cgroup 首次触碰的文件页）+ 内核内存（slab 中归属该 cgroup 的部分：socket buffer、dentry）——应用 RSS 只是其中一部分！常见事故：Java 服务 -Xmx 设为 limit 的 100% → 堆外（Metaspace、线程栈、DirectBuffer、CodeCache）+ 页缓存把 current 推过 limit → memcg OOM Kill（exit 137，dmesg 有记录但 K8s 事件只显示 OOMKilled）。防线设计：（1）limit ≥ 应用真实工作集 × 1.3（JVM 经验：Xmx ≤ limit 的 70-75%）；（2）监控 memory.current/memory.max 比值与 memory.events（low/high/max/oom 计数）而非只看应用堆指标；（3）memory.high（v2 软限）作为缓冲带：超过 high 后内核对该 cgroup 激进回收 + 分配路径减速（应用变慢但不死）——K8s 的 MemoryQoS 特性用它实现"软限流"；（4）页缓存的归属细节：cgroup v1 中缓存计入首次读写的 cgroup，v2 类似——文件 I/O 密集的容器要预留缓存空间或接受缓存被 limit 挤压（性能下降）；（5）swap：K8s 节点默认禁 swap（NodeSwap 特性 1.28+ beta 可选），有 swap 时 memory.swap.max 单独控制。诊断 OOMKilled：kubectl describe pod 看 exit code 与事件 → 节点 dmesg 看 memcg OOM 报告（含 cgroup 内存明细）→ 对照应用堆转储/NMT 找缺口。

容器内观测失真清单与正确姿势。（1）/proc/cpuinfo、/proc/meminfo、/proc/stat 显示宿主机资源——top/free/vmstat 在容器内的数字是宿主机口径（cgroupfs 不是 namespace 化的，lxcfs 可挂载伪 /proc 修正但非标配）；正确姿势：读 /sys/fs/cgroup/（v2 统一层级：cpu.max、cpu.stat、memory.current、memory.max、io.stat、pids.current）。（2）运行时自动配置事故库：JVM 按宿主机核数设 GC 线程与 ForkJoinPool（Java 8u191+ 的 UseContainerSupport 修复）、Go 的 GOMAXPROCS 读宿主机核数（1.19 前需 automaxprocs）、.NET 与 Node 的类似历史、线程池按 nproc 配置（Python multiprocessing.cpu_count 返回宿主机核数）——通用解法：显式配置并行度 = 配额核数，或用感知 cgroup 的库。（3）负载均值失真：/proc/loadavg 是宿主机的（容器看不到自己的 load）——用 PSI（cgroup 级的 /sys/fs/cgroup/cpu.pressure、memory.pressure、io.pressure，v2 提供）替代负载均值做容器内饱和度判断。（4）时间与时钟：容器共享内核时钟（无失真），但 /proc/uptime 是宿主机的。（5）网络观测：容器内 tcpdump 抓 eth0 是 veth 的容器端，宿主机侧要抓 veth 对端或 cni 网桥——两端排障时确认抓包点。

Kubernetes 调度与启动性能。Pod 启动时间分解（观测：kubectl get events、kubelet 日志、Pod conditions 时间戳）：Pending（调度中：资源不足/亲和约束/污点——scheduler 指标 scheduling_attempt_duration）→ ContainerCreating（镜像拉取：ImagePullBackOff 是常见卡点；volume 挂载：网络盘 attach + mount 可达分钟级——EBS 的 attach 是跨主机迁移的慢点）→ Running（容器创建 + 应用启动）→ Ready（readiness 探针通过——探针的 initialDelay/period 直接加到"可服务时间"上）。优化清单：镜像（瘦身：distroless/alpine 基底、多阶段构建；分层设计：依赖层不变则缓存命中；预拉取：DaemonSet 或调度器感知镜像局部性；按需加载：Nydus/SOCI 让容器在镜像完全下载前启动）；应用启动（JVM 的 CDS/AppCDS 与 CRaC 快照恢复、懒加载、并行初始化）；探针（startup probe 分离慢启动与就绪判断，避免 readiness 误杀慢启动应用）。调度器性能：大集群（5000 节点）的调度吞吐与延迟（scheduler_e2e_scheduling_duration_seconds P99）、抢占风暴（优先级配置不当导致连环驱逐）、拓扑分布约束（topologySpreadConstraints 的计算成本）。自动伸缩：HPA 的指标延迟（metrics-server 15-60 秒管道）+ 稳定窗口（默认 5 分钟缩容防抖）——突发流量下 HPA 响应滞后是容量事故根因，KEDA（事件驱动伸缩）与预测式伸缩是补充。

云盘性能的配额模型与诊断。以 EBS 为例的性能档位：gp3（基线 3000 IOPS/125MB/s 恒定 + 可独立加购至 16K IOPS/1000MB/s，与容量解耦——新默认之选）；gp2（3 IOPS/GB 线性于容量，<1TB 的盘性能随容量缩水，100GB 盘只有 300 IOPS/约 100MB/s——历史包袱陷阱）；io2 Block Express（最高 256K IOPS/4GB/s，数据库专用）；st1/sc1（吞吐型 HDD，500 IOPS 上限，大数据顺序负载）。突发机制：gp2 小盘（<1TB）有 burst bucket（基线以上突发到 3000 IOPS，额度按空闲积累）——"开发环境很快、压测十分钟后变慢"= 额度耗尽。延迟构成：guest 栈（10-50μs）+ virtio + 宿主机（数十 μs）+ 网络往返（100-300μs）+ 后端分布式写（3 副本 quorum）——单块 gp3 的 4K 随机读 P50 约 150-300μs（本地 NVMe 是 10-20μs，一个数量级差距）。诊断分层：guest 内 biolatency/biosnoop（设备延迟分布）→ 平台指标（VolumeQueueLength：宿主机侧排队深度——guest 内看不到，是"延迟高但 guest I/O 不忙"的解释；VolumeRead/WriteOps 对比配额上限——限流的直接证据；BurstBalance）。多盘并行（RAID0/LVM stripe）突破单盘上限、实例级 EBS 带宽上限（大规格实例才有高 EBS 带宽——小实例挂 16K IOPS 盘也跑不满）是容量规划的两个隐藏维度。

Serverless 与托管服务的性能特性。Lambda 类 FaaS：冷启动（容器/微 VM 初始化 + 运行时启动 + 代码加载：Python 百 ms 级、Java 秒级——Provisioned Concurrency 预热、SnapStart（Java 快照恢复）、轻量运行时与镜像瘦身是三大对策）；执行环境复用（warm 实例的 /tmp 与全局状态残留——性能受益但要注意状态泄漏）；并发与限流（账户级并发上限、每函数预留并发、突发并发的爬升速率——每秒翻倍式增长，压测流量瞬间打满会触发 Throttle）；下游连接问题（Lambda 并发 1000 = 数据库连接 1000？——RDS Proxy/连接池服务是标配）。托管数据库（RDS 类）：性能档位 = 实例规格 + 存储类型（gp3/io1）+ 网络（增强型网络），监控是云厂商口径（CloudWatch 的 60 秒粒度会平滑毛刺——Enhanced Monitoring 的 1 秒粒度与 Performance Insights 的 SQL 级分析才够诊断用）；参数组（max_connections、buffer pool）与自建不同但机制相同——本章的系统知识全部适用，只是观测入口换成平台工具。方法论：托管服务的性能分析边界在"平台指标 + 应用侧观测"，内部（宿主机、存储后端）是黑盒——SLA 与工单是黑盒部分的"观测工具"。

弹性伸缩的性能工程学。扩容路径的延迟构成：指标采集（15-60s）→ 伸缩决策（稳定窗口）→ 实例/Pod 创建（镜像拉取 + 调度：秒到分钟）→ 应用启动与预热（JIT 编译、缓存填充、连接池建立：Java 服务可达分钟级）→ 流量接入（LB 注册 + 健康检查）。总时长 = 各段之和，突发流量场景下这个"扩容时延"决定服务是否先被打挂。工程对策：（1）预热（warm pool：预启动的备用实例；Java 的流量染色渐进接入——新实例先接 10% 流量让 JIT 热身）；（2）余量设计（常态利用率 40-60%，留出扩容时延内的吸收空间——利用率红线与扩容速度的乘积关系）；（3）预测式伸缩（按历史周期提前扩：早高峰前 30 分钟）；（4）降级预案（扩容来不及时：限流、降级非核心功能、排队）；（5）缩容安全（connection draining：LB 停止新连接 + 等待存量完成；Pod 的 preStop hook + terminationGracePeriodSeconds——SIGTERM 后应用优雅关闭，K8s 默认 30 秒不够长连接排空）。观测：扩容事件的端到端时间线（从指标越限到新实例接流）、每次扩容期间的 SLO 违约量——这两个指标衡量"弹性系统的性能韧性"。

虚拟化网络与存储的数据路径开销。网络路径对比：传统 virtio-net（guest 驱动 → VM exit → 宿主机 QEMU/vhost-net → 宿主机栈 → 物理网卡）：每包多次上下文穿越，单流约 1-2M pps 上限、延迟 +20-50μs；vhost-user（数据面到用户态进程如 OVS-DPDK，共享内存环）：减少内核穿越；SR-IOV（VF 直通 guest，硬件交换）：接近物理性能（延迟 +2-5μs），但失去软件交换灵活性（安全组实现移到硬件或 eBPF）；智能网卡/DPU（Nitro 类：虚拟化功能卸载到专用硬件，宿主机 CPU 零占用——AWS Nitro 实例的"裸金属性能"来源）。存储路径：virtio-blk（单队列时代有锁瓶颈）→ virtio-blk 多队列 / virtio-scsi → vhost-user-blk（用户态后端，SPDK 集成）→ NVMe 直通（物理盘直给，无虚拟化层——本地实例存储 NVMe 的延迟就是裸设备延迟，但失去弹性迁移能力）。性能分析含义：实例类型决定数据路径——同是"云主机"，Nitro/SR-IOV 实例与老式 QEMU 实例的网络延迟差一个数量级；本地 NVMe 实例（i3/i4i 类）与 EBS 实例的存储延迟差 10 倍。选型时把"数据路径架构"作为性能参数看待。

多租户干扰的观测与缓解工具箱。干扰类型与观测：CPU 时间争抢（%steal，直接可见）；LLC 争抢（perf 的 LLC-load-misses 率上升而代码未变——需要历史基线对比；Intel RDT 的 CMT/MBM 监控每 cgroup 的缓存占用与内存带宽，云厂商部分开放）；内存带宽争抢（访存延迟上升、IPC 下降，MBM 或 perf -e uncore_imc 事件——guest 内通常不可见，靠基线漂移推断）；存储/网络后端争抢（延迟毛刺与平台指标的相关性分析）。缓解：独占实例（dedicated tenancy——物理机独享，合规与性能双需求）；大规格实例（占宿主机比例大，被挤压空间小）；实例类型选择（计算优化型 c 系列通常超售比内存型 r 系列激进——延迟敏感选低超售档位或裸金属）；应用层韧性（多副本 + 负载均衡 + 重试预算：单实例抖动被吸收——"接受干扰存在，设计容忍干扰的系统"是云原生性能哲学）；时间维度（业务高峰与云区域高峰的重叠分析，错峰调度批处理）。方法论：性能基线管理——同版本代码的 IPC/延迟/吞吐基线持续采集，漂移超阈值触发"环境变化"调查（steal、迁移事件、平台公告），把"看不见的邻居"变成"可检测的干扰"。

云成本与性能的联合优化。云上性能工作有直接的货币度量：单位成本性能（每美元处理的请求数）与单位性能成本（达成 SLO 的月度账单）。优化杠杆：（1）右规格化（rightsizing：利用率长期 <20% 的实例降档——监控数据驱动的定期审查，通常省 20-30%）；（2）实例类型套利（同代际的计算/内存/存储优化型价差、上一代实例的性价比、ARM 实例（Graviton 类）的 20-40% 单位成本优势——需验证应用兼容性与性能）；（3）Spot/抢占式实例（60-90% 折扣，无状态与可中断负载——批处理、CI、副本冗余的无状态服务；中断通知 2 分钟窗口的优雅处理）；（4）存储分层（热数据 gp3/io2、温数据 st1、冷数据对象存储 + 生命周期策略——存储成本常是账单暗角）；（5）性能优化直接降本（代码优化 30% CPU → 同 SLO 下实例数减 30%——性能工程的 ROI 在云上可精确计算，这是说服管理层投资性能工作的最硬论据）；（6）数据传输费（跨 AZ/Region 流量、公网出口——架构上数据本地性（计算靠近数据）既省延迟又省钱）。方法论：把"每请求成本"作为与 P99 并列的北极星指标，性能评审时同时看两个维度——云时代性能工程师的新技能是读懂账单。

云原生可观测性架构。三层数据源：（1）平台指标（云厂商监控：实例 steal/网络包丢弃/EBS 队列深度/LB 5xx——guest 内不可见的层次，必须接入）；（2）主机/容器指标（node_exporter/cadvisor + cgroup 口径的 CPU/内存/IO/PSI——注意 cadvisor 的容器指标是 cgroup 语义，与容器内 top 的宿主机语义不同）；（3）应用与追踪（OpenTelemetry：metrics/traces/logs 三信号统一采集，分布式追踪定位跨服务瓶颈，日志与 trace_id 关联）。架构要点：采集侧低开销常驻（计数器 + 低频 always-on 剖析），传输侧批量压缩，存储侧分层（热数据高基数时序库、冷数据对象存储）；高基数问题（每 Pod/IP/trace_id 一个时序的爆炸——标签设计规范）；采样策略（追踪的头部采样 vs 尾部采样：尾部采样保留错误与慢请求的全量 trace，是成本与诊断价值的平衡点）。排障工作流：告警（SLO 违约）→ 黄金信号大盘（哪个服务哪个指标）→ 追踪下钻（哪一跳慢）→ 实例定位（哪些 Pod 慢——全部慢是代码/依赖问题，个别慢是节点/干扰问题）→ 节点层分析（本章 + 前几章的工具：steal、throttle、PSI、biolatency）→ 平台指标（EBS 队列、网络丢弃）。这个"由外向内、由全局到实例"的漏斗是云原生排障的标准动线。

代码示例

mpstat 1 5
/* %steal 列：虚拟化争抢的直接指标 */
cat /proc/stat | head -1
/* cpu 行第 9 个数字是 steal 累计 jiffies */
systemd-detect-virt
/* 检测虚拟化类型：kvm/xen/vmware/none */
dmidecode -s system-product-name 2>/dev/null
/* 实例类型线索（云实例通常显示厂商型号） */
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-type
/* EC2 元数据服务：实例类型（各云有等价接口） */

虚拟化环境识别与 steal 观测。mpstat 的 %steal 是云性能检查的必选项：持续 >2% 记录基线、>5% 启动调查（对照云平台的实例事件——是否有宿主机维护/迁移、突发型实例的 CPU credit 是否耗尽：t2/t3 系列的 credit 机制是无上限性能的时间银行，耗尽后性能被钳到基线 10-40%）。/proc/stat 的 steal 累计值适合脚本化差分做长期趋势（性能漂移与 steal 趋势的相关性分析）。systemd-detect-virt 快速判断运行环境（容器内返回容器运行时名，虚拟机返回 hypervisor 类型——排障脚本的第一分支判断：物理机/虚拟机/容器的工具可用性不同，如容器内 perf 受宿主内核与 seccomp 限制）。元数据服务（169.254.169.254，各云通用地址）是实例自我认知的入口：实例类型、可用区、安全组、IAM 角色——性能脚本用它自动适配规格（如按实例类型查已知的网络/存储上限表，对比实测吞吐判断是否撞限）。注意元数据服务的安全（SSRF 风险，IMDSv2 的 token 模式必开）。方法论：云实例的性能报告必须包含环境上下文（实例类型、AZ、steal 基线），否则数据不可比——同一应用在不同规格实例上的"性能"是两个东西。

cat /sys/fs/cgroup/cpu.max
cat /sys/fs/cgroup/cpu.stat
/* nr_periods nr_throttled throttled_usec：限流三计数 */
cat /sys/fs/cgroup/memory.current; cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.events
/* low high max oom oom_kill 计数 */
cat /sys/fs/cgroup/cpu.pressure
cat /sys/fs/cgroup/memory.pressure
cat /sys/fs/cgroup/io.pressure
cat /sys/fs/cgroup/pids.current
/* cgroup v1 路径：/sys/fs/cgroup/cpu/cpu.cfs_quota_us 与 cpu.cfs_period_us */

容器内资源观测的正确姿势——直接读 cgroup 文件而非 /proc。cpu.max 输出"配额 周期"（如 "200000 100000" = 2 核；"max" 表示无限制）。cpu.stat 三计数是限流诊断核心：nr_throttled/nr_periods 比值 = 被限流的周期占比（>5% 即显著，配合第 12 章调优决策）；throttled_usec 是累计冻结时长——把它与应用 P99 毛刺的时间对齐就是铁证。memory.current/memory.max 是内存水位（比值 >85% 预警），memory.events 的 oom_kill 非零即发生过容器内 OOM（K8s 的 OOMKilled 事件源头），high 计数非零说明 memory.high 软限在生效（回收压力）。三个 pressure 文件是 cgroup 级 PSI——容器内唯一可信的饱和度指标（替代失真的 loadavg）：cpu.pressure 的 some 高 = 配额不足或争抢；memory.pressure 高 = 逼近 limit 的回收压力（OOM 前兆，比 current/max 比值更早预警）；io.pressure 高 = io.max 限流或设备饱和。pids.current 对比 pids.max 防 fork 炸弹式耗尽。脚本化建议：容器健康检查采集这八个文件做时序（它们都是零开销读取），比在容器内跑 top/vmstat（宿主机口径，误导）正确得多。cgroup v1 环境路径与文件名不同（cpu.cfs_quota_us、memory.usage_in_bytes、memory.stat），先 mount | grep cgroup 确认版本。

kubectl top pod -A --sort-by=cpu
kubectl describe node NODE | grep -A 8 "Allocated resources"
/* 节点资源承诺率：requests 总和 vs 容量 */
kubectl get pod POD -o jsonpath="{.status.conditions}" | jq
/* Pod 条件时间戳：调度/初始化/就绪的各时刻 */
kubectl get events --field-selector involvedObject.name=POD --sort-by=.lastTimestamp
crictl ps; crictl stats
/* 节点上的容器运行时视角 */
kubectl exec POD -- cat /sys/fs/cgroup/cpu.stat

Kubernetes 层的性能观测命令组。kubectl top（metrics-server 数据，15-60 秒粒度）做粗筛——注意它是瞬时采样均值，毛刺不可见，精确分析要进容器读 cgroup 或用 Prometheus 的 container_cpu_usage_seconds_total（rate 计算）。describe node 的 Allocated resources 显示 requests/limits 承诺率：CPU requests 总和超过 100% 即超售（throttle 与争抢风险），limits 总和远超容量是"纸面容量"（真实峰值会互相挤压）。Pod conditions 的时间戳链（PodScheduled → Initialized → ContainersReady → Ready）分解启动耗时：PodScheduled 晚 = 调度瓶颈（资源不足/约束复杂）；Initialized 到 ContainersReady 长 = 镜像拉取或应用启动慢（配合 events 的 Pulling/Pulled 时间差精确到镜像拉取段）。events 是启动问题的第一现场（FailedScheduling 的原因字段、ImagePullBackOff、probe failed）。crictl 是节点上的容器运行时 CLI（绕过 kubelet 直接看容器与镜像状态，stats 给容器级资源）。最后的 kubectl exec 读 cgroup 是"容器内正确观测"的落地——把第 2 个示例的八字文件检查做成 Pod 内巡检。组合工作流：top 粗筛异常 Pod → conditions/events 分解启动段 → exec 进容器读 cgroup 确认限流/内存压力 → 节点层 crictl 与平台指标收尾。

stress-ng --cpu 4 --timeout 60 &
/* 在 2 核配额的容器内跑 4 个 CPU worker，制造限流 */
watch -n 1 "cat /sys/fs/cgroup/cpu.stat"
/* 观察 nr_throttled 快速增长 */
/usr/share/bcc/tools/runqlat 10 1
/* 调度延迟直方图：应出现 ~100ms 量级的桶（周期边界解冻） */
cat /sys/fs/cgroup/cpu.max
/* 确认配额，如 200000 100000 */

CPU 限流的复现实验（容器内执行，需要 cgroup 配额已设）。原理验证链：4 个满载 worker 在 2 核配额下，每 100ms 周期只需 50ms 就耗尽 200ms 配额（4 核并行 × 50ms = 200ms），剩余 50ms 全体冻结——cpu.stat 的 nr_throttled 每周期 +1、throttled_usec 每周期 +50000 左右。runqlat 的直方图是限流的"指纹"：正常调度延迟在 μs 级桶，限流造成 ~50-100ms 的独立桶（任务 runnable 但被 cgroup 冻结，等待周期边界）——这个双峰形态（μs 峰 + 百 ms 峰）是区分"CPU 真饱和"（单峰右移）与"配额限流"（双峰）的关键证据。应用视角的后果：请求处理到一半被冻结 50ms，P99 直接 +50ms，而平均 CPU 利用率可能只有 50%（冻结时间不计入使用）。修复验证：把 worker 数降到 2（匹配配额）重测——nr_throttled 停止增长、runqlat 百 ms 桶消失，但总吞吐下降（并行度受限）；或把配额提到 4 核（cpu.max 改 400000）——两者都恢复但语义不同（降并行是应用适配配额，加配额是资源适配应用，生产决策看成本与延迟预算）。这个 15 分钟实验是理解 K8s CPU limit 争议（"要不要设 limit"）的最佳教材。

fio --name=cloudvol --ioengine=libaio --direct=1 --rw=randread --bs=4k --iodepth=32 --numjobs=4 --size=2G --runtime=300 --time_based --filename=/data/fio.test --log_avg_msec=1000 --write_iops_log=iops
/* 5 分钟 4K 随机读，每秒记录 IOPS 时序——观察云盘突发额度耗尽 */
iostat -xz 1 300 | awk "/nvme|sd|xvd/ {print strftime(\"%H:%M:%S\"), $0}"
/usr/share/bcc/tools/biolatency 10 30
/* 每 10 秒一轮延迟直方图，观察限流时直方图右移 */

云盘性能与限流的实测方法。核心思路：云盘的性能上限是配额（IOPS/带宽），撞限的表现是"延迟上升而 guest 内看不到设备忙"——因为限流发生在宿主机/后端层。fio 的 --write_iops_log 每秒记录 IOPS 时序：对 gp2 类突发盘，前 5-10 分钟 IOPS 在 3000（burst），额度耗尽后跌到基线（如 100GB 盘的 300）——IOPS 时序图的台阶就是突发额度的形状；对 gp3/io2 恒定配额盘，IOPS 应稳定在配额线（3000/16000），超过配额的请求表现为延迟上升而非 IOPS 上升。biolatency 分时段直方图：限流前 P50 约 200μs（云盘正常），限流后整体右移到 ms 级（请求在宿主机队列排队——guest 内的"设备延迟"实际含平台限流排队）。同步对照平台指标（CloudWatch 的 VolumeQueueLength、VolumeReadOps 对比配额）：VolumeQueueLength 上升 + guest IOPS 顶在配额线 = 限流确认。诊断决策树：IOPS 达配额 + 延迟高 → 加购 IOPS 或换档位；IOPS 远低于配额 + 延迟高 → 后端问题或实例级 EBS 带宽上限（大 IOPS 盘需要大实例才发挥——实例规格的 EBS 带宽是隐藏上限）；突发盘额度耗尽 → 换 gp3（恒定基线）或加大容量。这个实验把"云盘玄学"变成可测量的配额工程。

sysbench cpu --threads=$(nproc) run
/* 容器内 CPU 基准：对比宿主机同负载的 events/s */
sysbench memory --memory-block-size=1K --memory-total-size=10G run
/* 内存带宽基准：LLC/内存带宽干扰的检测器 */
perf stat -a sleep 10 2>&1 | grep "insn per cycle"
/* IPC 基线：邻居干扰的敏感指标 */
sockperf ping-pong -i TARGET --tcp -t 30
/* 网络栈延迟基线 */
for i in 1 2 3; do fio --name=lat --ioengine=libaio --direct=1 --rw=randread --bs=4k --iodepth=1 --runtime=10 --time_based --filename=/data/fio.test 2>&1 | grep "99.00th"; done
/* 存储 P99 延迟基线 */

云实例性能基线套件——检测"环境漂移"的定期巡检。设计思想：云环境的干扰（邻居、迁移、平台劣化）无法直接观测全貌，但可以用"标准负载的实测性能"做金丝雀：每周（或每次性能异常时）跑同一套基准，结果与历史基线对比，漂移 >10% 即触发环境调查。五个探针各测一层：sysbench cpu 测纯计算（对 steal 与频率敏感——events/s 下降先查 mpstat %steal）；sysbench memory 测内存带宽（对 LLC 与内存带宽干扰敏感——这层干扰 steal 看不到，只有带宽基准能暴露）；perf stat 的 IPC 是综合效率指标（代码不变 IPC 漂移 = 微架构级干扰或频率变化）；sockperf 测网络栈往返（虚拟化网络路径劣化、宿主机网络压力）；fio QD1 的 P99 测存储延迟基线（云盘后端劣化、宿主机存储压力）。实施要点：固定实例规格与 AZ 记录上下文；每项跑 3 次取中位数（云环境方差大）；基线数据入时序库画趋势（漂移的可视化比单点更有说服力）；异常时的对照实验——同规格新实例跑同套基准（新实例正常 = 老实例的宿主机问题，考虑迁移/重部署；新实例也异常 = 平台级或 AZ 级事件，查平台公告与工单）。这套"性能金丝雀"是云原生 SRE 的基础设施，把不可见的多租户世界变成可测量的漂移信号。

实验笔记

实验十：云与容器环境性能分析综合实验。

实验目标：（1）在容器中复现并诊断 CPU 限流与内存 OOM 两大经典问题；（2）验证容器内观测失真（/proc 宿主机口径）并建立 cgroup 口径的观测习惯；（3）测量容器相对宿主机的性能税（网络、存储、CPU）；（4）（有 K8s 环境者）完成一次 Pod 启动时间分解。

环境准备：方案 A（推荐）：一台 Linux 主机 + Docker/Podman；方案 B：kind/minikube 单节点 K8s；方案 C：云厂商免费层实例。主机安装 stress-ng、sysbench、fio、iperf3、BCC tools。所有对比实验先在宿主机（或独立 VM）记录基线。

步骤一（观测失真验证）：起一个 2 核 1GB 限制的容器（docker run --cpus=2 --memory=1g -it ubuntu bash）。容器内执行：nproc（可能显示宿主机核数！）、cat /proc/cpuinfo | grep -c processor（宿主机核数）、free -m（宿主机内存）、cat /proc/loadavg（宿主机负载）、top（宿主机口径）。再读正确口径：cat /sys/fs/cgroup/cpu.max（应显示 200000 100000）、memory.max（1073741824）、cpu.pressure。写一个 container_aware_resources.sh：输出"配额核数、内存上限、当前用量、PSI 三项"，作为容器内资源观测的标准脚本。思考：哪些运行时/库会因 nproc 失真而配置错误？（JVM GC 线程、Go GOMAXPROCS、Python multiprocessing、各种线程池默认值。）

步骤二（CPU 限流复现与诊断）：容器内跑 stress-ng --cpu 4 --timeout 120（4 worker 对 2 核配额）。宿主机或容器内每秒采集 cpu.stat（nr_throttled/throttled_usec 增速）与 runqlat（如容器内可用 BCC；否则用宿主机对容器 cgroup 观测）。记录：限流周期占比、runqlat 的百 ms 桶、stress-ng 报告的 CPU 时间（对比无限制容器——限流下有效 CPU 时间减半）。修复对比：--cpu 2 重跑（限流消失）。再验证 GOMAXPROCS/JVM 类问题：容器内跑 sysbench cpu --threads=8 与 --threads=2 对比 events/s 与 throttled_usec——线程数超配额不仅无益反而加剧限流毛刺。

步骤三（内存 OOM 复现）：容器内（1GB 限制）跑 stress-ng --vm 1 --vm-bytes 1200M --vm-keep。观察：memory.current 逼近 memory.max、memory.pressure 的 full 值飙升、memory.events 的 oom_kill 计数 +1、容器被杀（exit 137）。宿主机 dmesg 查看 memcg OOM 报告（含 cgroup 内存明细：anon/file/slab 分解）。再做"页缓存计入"实验：512MB 限制容器内 dd 读一个 400MB 文件两遍，观察 memory.current 中 file 缓存的增长（memory.stat 的 file 字段）——理解"容器内存 = 应用 + 缓存 + 内核"的完整账本。验证 memory.high 软限（Podman/cgroup v2 直接写 memory.high 为 400M）：超过 high 后应用变慢（回收压力）但不被杀——对比硬限的行为差异。

步骤四（容器性能税测量）：CPU：宿主机与容器内各跑 sysbench cpu --threads=1（无限制容器），对比 events/s（预期差异 <2%——容器 CPU 几乎无税）。内存：sysbench memory 对比（预期 <2%）。存储：同一磁盘目录，宿主机与容器（bind mount 与 overlayfs 两种）各跑 fio 4K 随机写 QD16——bind mount 应无差异，overlayfs 上写新文件有 CoW 开销（对比首次写与重写）。网络：宿主机-容器 iperf3（bridge 网络 vs host 网络模式），对比带宽与 CPU 占用（bridge 的 veth + NAT 税预期 5-15%）；sockperf ping-pong 测延迟差（bridge 模式预期 +10-30μs）。汇总成"容器性能税表"，标注每项的机制（namespace 穿越、overlayfs CoW、veth 双栈）。

步骤五（K8s Pod 启动分解，方案 B/C 环境）：部署一个 Java 应用 Pod（用公开镜像如 spring-petclinic），kubectl get pod -o jsonpath 提取 conditions 各时间戳，分解：调度耗时（created → PodScheduled）、镜像拉取（events 的 Pulling → Pulled）、容器启动到就绪（Started → Ready，含应用启动与探针）。优化实验：（a）预拉镜像（节点上先 docker pull）后重建 Pod，对比镜像段耗时；（b）调整 readiness probe 的 initialDelaySeconds 与 periodSeconds，观察 Ready 时间的变化（探针粒度造成的"虚假启动慢"）；（c）对比 requests/limits 不同配置下的调度与启动行为。写一份"Pod 启动时间瀑布图"。

预期结果：容器资源观测脚本、限流复现数据（throttled_usec 增速 + runqlat 双峰）、OOM 的 memory.events 与 dmesg 报告、容器性能税对照表、（K8s）启动时间瀑布图。

进阶挑战：（1）用 cgroup v2 的 io.max 给容器设 IOPS 上限，验证 io.pressure 与 biolatency 的变化（容器 I/O 隔离）；（2）在限流容器中跑一个真实 Web 服务（如 nginx + wrk 打压），量化限流对 P99 的影响（对比无限制），并验证"降 worker 数匹配配额"的修复效果；（3）模拟突发型实例：用 cgroup 写一个"前 60 秒 4 核后 1 核"的配额切换脚本，观察应用延迟的台阶变化（理解 t2/t3 credit 机制）；（4）测量镜像按需加载（如可用 Nydus/estargz 环境）对比完整拉取的启动时间差异。

第10章 云计算性能