云实例里看到的 CPU、磁盘和网络通常是虚拟资源，物理上还隔着资源控制、管理程序、宿主机和共享服务。实例未到“100%”也可能先碰到配额，容器内的传统工具还可能显示宿主机总量。本章解决如何确认故障属于应用、容器/虚拟机、资源限制、宿主机竞争还是云服务，并避免把所有不可见抖动都归咎于“吵闹邻居”。

1. 云性能首先受实例和 cgroup 限额约束，软件限制通常比物理资源上限更早触发。
2. 客户机视角天然不完整。虚拟机可分析自己的内核却看不到物理竞争；容器运营方可见性高，容器用户却常无法深入内核。
3. 硬件虚拟机、容器和轻量虚拟机的差异不仅是开销，还包括启动时间、内存损失、隔离强度与可观测性。
4. 自动扩缩容必须是带验证的闭环。攻击、软件退化或错误指标也会触发扩容，把性能缺陷放大为成本。
5. 网络存储和多租户会增加延时方差。跨实例基线、完整分布和宿主机侧证据，比一次平均测试更可信。

一次请求可能经过负载均衡、Pod/实例、进程、cgroup、宿主机调度、管理程序或虚拟设备，最后抵达共享存储与网络。诊断时要为每一层标出“需求、分配、限制、使用、等待”。物理资源空闲并不能否定租户限额，租户工具报告繁忙也不一定代表自己的容器在工作。

1. 画出部署边界：实例类型、虚拟化方式、Pod/容器、节点、存储和网络服务，确认近期迁移或规格变化。
2. 记录业务现象与扩缩容事件，先排除请求增长、发布退化和错误指标触发的容量变化。
3. 在租户侧执行常规 USE 检查，同时看 CPU steal、虚拟设备延时与 PSI；这些只能提供线索，不能直接证明物理根因。
4. 检查 requests/limits 与 cgroup 统计，重点看 CPU 节流时间、memory events、OOM 和 I/O/网络限额。
5. 若有宿主机权限，对齐同一时间窗的物理资源、管理程序、其他租户和虚拟 I/O；没有权限则收集可复现证据交给运营方。
6. 用同规格多实例或多时段对照。只有延时异常与自身负载、大小和访问模式都无关，才更支持外部竞争或底层设备问题。

以下为只读检查。cgroup v1 与 v2 的目录和字段差异很大，先识别版本，再按平台文档选路径。

docker stats --no-stream

systemd-cgtop

cat /proc/self/cgroup

stat -fc %T /sys/fs/cgroup

cat /sys/fs/cgroup/cpu.stat

cat /sys/fs/cgroup/memory.current

cat /sys/fs/cgroup/memory.max

cat /sys/fs/cgroup/memory.events

vmstat 1 5

mpstat -P ALL 1 5

kubectl top pod --containers

kubectl describe pod POD

上述 cgroup 文件示例偏向 v2；v1 常见 cpu.stat、memory.limit_in_bytes 和 blkio 文件位于各控制器目录。kubectl top 依赖指标服务，describe 展示的是声明与事件而非完整性能历史。容器内 iostat、free 等传统工具可能呈现宿主机级数据，必须先确认它们是否具备容器感知。

cpu.stat 中 nr_throttled 与 throttled_usec 持续增加，说明 CPU 带宽限制正在执行；CPU 使用率没有到宿主机满载也可能被节流。memory.current 接近 memory.max，并且 memory.events 中 high、oom 或 oom_kill 增长，说明内存限制而非宿主机容量是首要问题。虚拟机中的 steal 持续升高表示 vCPU 本可运行却未获得物理 CPU，但还要结合云配额与管理程序证据解释。

docker stats 的 CPU 百分比可跨多个 CPU，不能机械地以 100% 为上限。容器内 iostat 显示磁盘繁忙，而自身 cgroup I/O 计数不增长，可能是它看到了其他租户或宿主机活动。扩容后单位请求成本上升、延时不降，则应检查软件退化或下游瓶颈，而非继续加副本。

在 Kubernetes 中，request 主要参与调度与最低资源预期，limit 决定可用上限；两者缺失或比例不合理都会让节点装箱和节流表现偏离预期。对比实例时还应固定实例家族与代际，因为同名规格背后的处理器、存储路径和突发策略可能不同。一次迁移成功不能替代多时段回归。

• 把实例标称 vCPU 当成始终独占的物理 CPU，忽略 steal、共享和爆发额度。
• 只看宿主机尚有空闲，就否定容器限额或云配额造成的节流。
• 在容器内看到全机 iostat 很忙，便认定自己的进程制造了这些 I/O。
• 把任何随机抖动都称为吵闹邻居，没有排除自身负载、I/O 大小和发布变化。
• 自动扩缩容只盯 CPU；下游存储、连接数、启动时间和成本可能先成为约束。
• 只跑一次微基准比较虚拟化方案，忽视可观测性和多租户方差。

1. 宿主机空闲但容器 CPU 很慢，先查什么？答：容器 CPU requests/limits 与节流统计。
2. 虚拟机 steal 持续升高表示什么？答：vCPU 有运行需求，却未获得相应物理 CPU 时间。
3. 容器内 iostat 很忙能证明是本容器负载吗？答：不能，工具可能显示宿主机总量。
4. 自动扩容为何可能放大故障？答：攻击或软件退化也会被当作正常负载并复制到更多实例。
5. 哪类虚拟化通常给客户机最完整的内核观测能力？答：拥有专用内核的硬件或轻量虚拟机。

云性能分析的本质是补齐层级与所有权：业务、租户限制、虚拟化、宿主机和共享服务都要有相同时间窗的证据。先检查最接近租户的配额与节流，再请求更低层数据；把扩缩容、性能和成本放在同一闭环中验证。

• PDF 628-635 页：实例类型、横向扩展、动态容量、云存储、多租户与 Kubernetes。
• PDF 636-654 页：硬件虚拟化、资源控制、宿主机/客户机可观测性与 steal。
• PDF 655-678 页：Linux 容器、命名空间、cgroup、开销、节流与容器感知工具。
• PDF 679-687 页：轻量虚拟化、其他云形态、技术比较、练习与参考资料。