系统性能排查是后端开发和运维工作中绕不开的核心技能。无论是上线前压测、线上告警处理还是日常资源规划都需要先看懂机器的运行状态才能判断瓶颈到底落在哪里。很多开发者在排查问题时习惯只看某个单一指标比如 CPU 飙高就以为是计算密集结果优化了大半天才发现真正的瓶颈是磁盘 I/O 或网络重传。本文围绕 GPU 使用率、CPU 使用率、CPU 上下文切换、内存使用率、磁盘 I/O、网络 I/O 六个维度展开结合 Linux 常用监控工具与完整分析方法说明每一项指标如何采集、如何解读、如何联动定位系统瓶颈并给出生产环境下的最佳实践。1. 性能监控的底层逻辑与核心概念1.1 为什么需要同时观察六类指标一台服务器的资源是有限的任何程序运行都会消耗 CPU、内存、磁盘、网络和 GPU如果涉及模型训练或推理。这些资源不是孤立工作的例如一次普通的数据库查询会同时产生 CPU 计算、内存读取、磁盘 I/O、网络传输一个深度学习训练任务会同时消耗 GPU 算力、CPU 数据预处理能力、内存带宽和磁盘读取能力。如果只观察其中一个指标很容易被表面现象误导。典型的例子是GPU 利用率很低但训练速度非常慢表面看是 GPU 资源不足实际可能是 CPU 数据加载太慢GPU 一直在等待数据这时候真正需要优化的是数据加载管道。因此系统性能监控的核心思路是把六个维度的指标放在同一时间轴上对比分析通过“资源使用率 等待状态 吞吐量”的组合判断瓶颈位置。单看使用率高不高没有意义重点是搞清楚谁在等谁。1.2 关键指标的分工定位六类指标可以从“资源类型”和“瓶颈方向”两个维度进行分类指标资源类型重点关注方向典型工具GPU 使用率计算加速资源算力是否打满、显存容量、GPU 等待nvidia-smi、nvtopCPU 使用率计算资源用户态/内核态占比、I/O 等待、负载top、vmstat、mpstatCPU 上下文切换调度/内核开销线程数量、锁竞争、中断处理vmstat、pidstat内存使用率存储资源可用内存、缓存、换页、OOM 风险free、vmstat磁盘 I/O存储 I/O吞吐量、IOPS、延迟、队列长度iostat、iotop网络 I/O网络资源带宽、PPS、重传、握手队列sar、nload、ifstat从瓶颈方向来看CPU 使用率高代表计算资源紧张或者程序写得不合理。CPU 使用率不高但系统响应慢可能瓶颈在磁盘、网络或锁等待。上下文切换频繁代表系统在大量切换执行任务可能线程过多或中断过多。内存使用率高需要区分是缓存占满还是应用真实消耗。磁盘 I/O 饱和通常表现为 CPU 的 iowait 升高进程阻塞在 I/O 上。网络 I/O 饱和通常表现为延迟升高、重传增加、丢包率上升。这些指标之间是相互印证的关系。单独看任何一个指标都有局限组合在一起才能还原出系统的真实运行链路。2. 环境准备与监控工具安装说明2.1 操作系统与工具链本文示例以 Linux 环境为主因为大多数服务器、容器宿主机和 AI 训练节点都运行在 Linux 上。如果你使用的是 CentOS、Ubuntu、Debian、Rocky Linux下面这些工具基本都可以通过系统包管理器安装。Windows 环境下的性能监控如 PerfMon 和任务管理器不在本文范围内但分析思路完全相通。工具清单如下工具所属包核心用途top / htopprocps / htop实时查看进程、CPU、内存mpstatsysstat查看每个 CPU 核心的使用率明细vmstatprocps查看系统整体的运行队列、内存换页、CPU 等待pidstatsysstat按进程维度查看 CPU、上下文切换、I/Ofreeprocps查看内存总量、使用量、缓存iostatsysstat查看磁盘 I/O 吞吐量、利用率、等待时间iotopiotop按进程实时查看磁盘 I/Osarsysstat历史性能数据采集与回放nvidia-smiNVIDIA 驱动自带查看 GPU 使用率、显存、温度、功耗nvtopnvtopGPU 监控的交互式界面nload / iftopnload / iftop实时查看网络流量ss / netstatiproute2 / net-tools查看网络连接状态、队列信息需要注意不同发行版安装命令不同。CentOS/RHEL 系使用yum install -y sysstat htop nload iftopUbuntu/Debian 系使用apt install -y sysstat htop nload iftop。NVIDIA 驱动本身自带 nvidia-smi无需单独安装nvtop 需要额外安装并且会读取 NVML 库来获取 GPU 信息。版本方面不同版本的 sysstat 输出字段会有细微差别比如较新的 iostat 增加了更多列。本文示例以常见稳定版本输出为准实际使用中只需关注关键列即可。2.2 确保监控数据可回溯临时看实时数据可以使用 top、vmstat 这类工具但生产环境更推荐搭配 sar 做历史数据采集。sysstat 安装后需要确认/etc/cron.d/sysstat或 systemd 定时器已经启用默认每 10 分钟采集一次数据。使用下面命令查看当前是否正常采集sar -u 1 3如果输出有数据说明历史采集已生效。如果没有输出先启动 sysstat 服务systemctl start sysstat systemctl enable sysstat有了历史数据线上出问题时才能回顾“故障发生前半小时内存是怎么变化的”“磁盘 I/O 是什么时候开始飙高的”这一点在故障复盘时非常关键。3. GPU 使用率AI 训练的算力窗口3.1 使用 nvidia-smi 查看 GPU 基础状态在深度学习训练、模型推理、科学计算场景中GPU 使用率是最直观的算力指标。执行命令nvidia-smi输出信息非常丰富----------------------------------------------------------------------------- | NVIDIA-SMI 525.85.12 Driver Version: 525.85.12 CUDA Version: 12.0 | |--------------------------------------------------------------------------- | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | || | 0 Tesla T4 On | 00000000:00:1E.0 Off | 0 | | N/A 54C P0 31W / 70W | 2116MiB / 15360MiB | 12% Default | | | | N/A | ---------------------------------------------------------------------------关键字段的含义GPU-Util是 GPU 计算单元利用率表示采样时间内 GPU 上活跃计算任务占用的时间比例。需要注意12% 不代表 GPU 只用了 12% 的容量它代表有 12% 的时间有核在执行计算指令中间大量时间可能是在等待数据。Memory-Usage是显存使用量深度学习场景中显存不足会直接报 CUDA Out Of Memory所以显存和利用率需要同时看。Temp是 GPU 温度高负载下温度长期接近或超过 85°C 时需要检查散热或降频。Pwr:Usage/Cap是当前功耗和最大功耗功耗接近上限说明 GPU 已经满载工作。3.2 如何正确理解 GPU 利用率偏低训练模型时如果 GPU 利用率长期低于 50%通常不是 GPU 本身算力不够而是训练管道中存在瓶颈。常见原因包括CPU 负责数据加载和预处理如果 CPU 处理不过来GPU 只能空转等待。数据读取走磁盘磁盘 I/O 跟不上数据加载速度。训练脚本中每个 step 内做了大量同步操作、日志打印或评估逻辑。模型存在大量小算子GPU 计算密集度不够启动和调度开销占比过高。多卡训练时通信开销过大GPU 在等待参数同步。使用nvidia-smi dmon可以按固定间隔持续输出 GPU 状态适合后台采集nvidia-smi dmon -s puct -d 1-s参数指定要显示的指标组p代表功耗u代表利用率c代表计算相关统计t代表温度-d 1表示每秒采集一次。如果 GPU 利用率和功耗同时偏低很大概率是数据供给不足或任务同步等待。3.3 在训练脚本中实时监控 GPU 状态除了在宿主机上执行命令也可以在 Python 训练脚本中通过pynvml或nvidia-ml-py获取 GPU 信息把 GPU 利用率和显存写入日志方便分析训练过程中 GPU 的变化曲线。示例思路如下import pynvml import time pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) for _ in range(10): util pynvml.nvmlDeviceGetUtilizationRates(handle) mem pynvml.nvmlDeviceGetMemoryInfo(handle) print(fGPU 利用率: {util.gpu}%, 显存占用: {mem.used // 1024**2} MB) time.sleep(1)这不是生产级代码但给出了一个很关键的思路当训练日志和 GPU 监控日志时间轴对齐后就能定位到某个具体 step 是否发生了 GPU 空等问题。4. CPU 使用率从整体到单核的逐层拆解4.1 top 命令中的 CPU 使用率不代表全部执行top后最上方会看到类似这样的 CPU 汇总%Cpu(s): 20.3 us, 5.2 sy, 0.0 ni, 73.8 id, 0.5 wa, 0.0 hi, 0.2 si, 0.0 st字段含义us是用户态 CPU 占比应用程序计算逻辑消耗的 CPU。sy是内核态 CPU 占比系统调用、驱动、内核管理消耗的 CPU。ni是 nice 值调整过的进程 CPU 占比通常用于低优先级任务。id是空闲占比越大说明 CPU 越空闲。wa是 I/O 等待占比代表 CPU 在等待磁盘或网络 I/O 完成。hi是硬件中断占比通常与网卡、磁盘控制器等硬件处理相关。si是软件中断占比网络收发、定时任务等会消耗这部分 CPU。st是被虚拟机管理程序偷走的 CPU 时间占比在云服务器上常见。这里最容易被忽略的是wa。CPU 使用率只有 20%但wa占 30%说明进程并没有吃饱 CPU而是大量时间卡在 I/O 上。此时操作系统显示 CPU 在等待实际上业务响应慢的根源是磁盘不是 CPU。按P键可以按 CPU 占用排序快速定位消耗最高的进程。按1可以展开每个 CPU 核心的使用情况便于判断是某个核打满还是均匀负载。4.2 使用 mpstat 查看多核分布多核机器上单个进程可能只跑在一个核上。如果程序是单线程的即使其他核都空闲这个核也可能达到 100%从整体 CPU 使用率上看可能只有 12.5%。排查这类问题需要逐核分析mpstat -P ALL 2 5输出示例Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: all 30.25 0.00 5.10 2.30 0.00 0.85 0.00 0.00 0.00 61.50 Average: 0 90.50 0.00 8.25 0.00 0.00 0.50 0.00 0.00 0.00 0.75 Average: 1 5.10 0.00 2.30 3.20 0.00 0.40 0.00 0.00 0.00 89.00可以看到整体空闲 61.5%但 CPU 0 已经几乎打满。这种情况下的优化方向是让单线程程序改用多进程/多线程或者通过taskset做绑核优化避免线程在不同核之间频繁迁移。4.3 CPU 使用率突高的排查路径遇到 CPU 使用率突高按以下顺序排查先用top -c找到 CPU 占用最高的进程。用top -Hp pid查看该进程内部哪些线程消耗 CPU 最高。如果是 Java 应用使用jstack导出线程栈结合线程 ID 定位到具体代码位置。如果是 Python 应用使用py-spy dump --pid pid查看当前 Python 函数调用栈。如果是 Node.js 应用使用node --prof-process分析 CPU profile。不要一看到 CPU 高就直接改代码。先确认是业务线程跑满、GC 线程跑满、还是定时任务集中执行再针对性处理。例如 Java 应用 GC 线程占满 CPU 时盲目加业务线程只会让情况更糟。5. CPU 上下文切换线程调度与内核开销的信号灯5.1 什么是 CPU 上下文切换操作系统在多个线程之间分配 CPU 时间片时需要保存当前线程的执行状态寄存器、程序计数器、内核栈等再加载下一个线程的状态这就是一次上下文切换。频繁的上下文切换本身会消耗 CPU 时间更严重的是会导致 cache 失效后续访问内存的延迟变高。Linux 中进程、线程的切换是上下文切换中断处理也是上下文切换的一种。前者称为任务切换后者包括硬件中断和软件中断处理带来的切换开销。使用vmstat 1 5查看cs列procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 163456 512 20480 0 0 0 0 1200 8000 12 5 82 0 0cs列就是每秒上下文切换次数。单独一次看可能很难判断好坏需要结合 CPU 核心数和线程规模来评估。判断思路对于 8 核机器每秒上下文切换 8000 次约每核 1000 次/秒通常处于正常范围。如果每秒超过 20000 次并且持续增长大概率存在线程过多或锁竞争问题。上下文切换高但 CPU 整体空闲说明线程在频繁睡眠/唤醒典型的锁等待场景。上下文切换高且si软中断占用高可能是网络小包洪峰或网卡多队列配置不合理。5.2 按进程查看上下文切换使用pidstat -w可以按进程维度观察pidstat -w 2 5输出中cswch/s是自愿上下文切换次数nvcswch/s是非自愿上下文切换次数。这里有一个非常重要的区分自愿切换高说明线程在等待锁、等待 I/O、主动 sleep。非自愿切换高说明线程的时间片被抢占常见原因是线程数量远大于 CPU 核心数或者有更高优先级的任务在抢占。生产环境中如果nvcswch/s非常高优先检查线程池大小是否设置过大。典型误区是为了提升并发能力把线程池设成几千结果大量线程都在等待任务反而导致频繁上下文切换吞吐量下降。这时候减少线程数通常比增加线程数更有效果。5.3 软中断与硬中断带来的切换开销网络数据包到达网卡后会触发硬中断通知 CPU 处理硬中断处理完后剩余工作交给软中断。高 PPS每秒数据包数场景下软中断可能长期占满某个 CPU 核心。检查方法cat /proc/softirqs cat /proc/interrupts如果NET_RX软中断集中在 CPU 0 上说明网卡没有开启多队列或者 CPU 亲和性没有配置好。现代 Linux 和网卡驱动支持 RSSReceive Side Scaling可以将不同队列的中断绑定到不同 CPU 核心避免单核软中断打满。这是网络密集型服务需要重点关注的方向。6. 内存使用率从 free 输出到 OOM 风险6.1 free 命令各列的真实含义执行free -htotal used free shared buff/cache available Mem: 31Gi 12Gi 2.1Gi 100Mi 17Gi 18Gi Swap: 4.0Gi 512Mi 3.5Gi这里容易搞混的是free和available。free是完全没有被使用的物理内存buff/cache是 Linux 用来缓存磁盘文件和页面缓存的内存。这部分内存在应用需要时可以自动回收所以真正可用内存要参考available列。系统显示 2.1Gi free不代表内存不够用因为 17Gi buff/cache 在需要时可以释放。真正需要警惕的是available持续下降并接近 0这意味系统可能要开始 swap 或触发 OOM Killer。当si从磁盘交换入内存和so从内存交换出到磁盘两列持续有数值时说明内存已经在频繁换页性能会显著下降。6.2 按进程定位内存占用使用top -o %MEM可以按内存占用率排序快速找出内存大户。但 Linux 中进程 RSS 有两个需要注意的地方RSS 是进程独占的物理内存不包含共享库中其他进程也引用的部分。多个进程通过fork()生成时会共享父进程的物理内存页RSS 会出现重复计数。如果要精确分析可以查看/proc/pid/smaps中的 PSSProportional Set Size它把共享内存按进程数分摊计算。日常使用smem工具更方便smem -rk | head -206.3 内存问题的常见表现内存问题不只是“不够用”这一种。实际生产环境中的典型场景现象可能原因查看方式available 持续低无明显进程占用页缓存持续增长但回收不及时cat /proc/meminfo查看 MemAvailable应用报 OOM但系统内存还有剩余cgroup 内存限制或容器内存限制cat /sys/fs/cgroup/memory/memory.limit_in_bytes大量换页导致 CPU sys 高swap 频繁读写vmstat 中 si/so 持续非零频繁执行 GC 或进程崩溃堆内存/缓存设置不合理内存碎片应用日志 GC 日志在容器环境中还要注意容器通过 cgroup 限制内存后free看到的是宿主机内存而不是容器内存。判断容器是否内存超限需要查看 cgroup 目录下的memory.max和memory.current不能只看free输出。7. 磁盘 I/O延迟、吞吐与利用率7.1 使用 iostat 拆分磁盘状态执行iostat -x 2 5关键列含义r/s和w/s是每秒读/写请求次数对应 IOPS。rkB/s和wkB/s是每秒读/写吞吐量。await是 I/O 请求处理的平均等待时间毫秒包含排队时间和实际处理时间。%util是设备忙绿时间占比反映磁盘的繁忙程度。svctm目前 iostat 已不再推荐使用该值估算服务时间更多作为参考。%util接近 100% 代表磁盘已经饱和但不同磁盘型号对饱和的定义不同。普通机械盘在 80% 以上基本接近极限而 NVMe SSD 即使 %util 到 100%延迟可能还在毫秒级整体性能依然可以接受。因此await才是更直观的体验指标机械盘 await 在 10~20ms 以内算正常。SSD 在 1~2ms 以内算正常。云盘受网络和虚拟化影响延迟标准要根据云厂商文档确定。7.2 按进程定位磁盘读写iostat看到的是系统整体磁盘状态定位哪个进程在产生 I/O 需要使用iotopiotop -oP-o只显示正在执行 I/O 的进程-P显示进程而不是线程。对于 Java 应用还可以通过lsof -p pid | grep deleted发现日志文件被删除仍被占用、磁盘空间无法释放的问题。这类细节问题在生产环境很常见但容易被忽略。7.3 磁盘 I/O 与文件系统层面的隐藏坑磁盘延迟不只来自硬件本身还来自文件系统、锁和配置ext4的auto_da_alloc特性可能导致数据库类应用在fsync时性能下降。容器使用 overlayfs 时大量小文件读写会放大 I/O 开销。日志框架在使用同步刷盘模式时每条日志都会触发fsync导致 I/O 吞吐大幅下降但 iostat 中%util可能并不高因为等待在发生在锁上。遇到磁盘 I/O 异常时先看await是否高再看%util是否打满最后再往上定位是文件系统、应用层还是硬件本身。8. 网络 I/O带宽、PPS 与连接跟踪8.1 查看实时网络流量使用sar -n DEV 2 5可以查看网络接口的实时吞吐Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil Average: eth0 12000.50 11020.30 15360.20 12440.10 0.00 0.00 0.00 6.20rxpck/s和txpck/s是每秒收发包数量rxkB/s和txkB/s是每秒收发字节数。需要注意带宽打满不代表 PPS 打满反之亦然。比如一个网卡带宽 10Gbps但每个包只有 64 字节小包洪峰可能导致 PPS 达到上限而带宽使用率只有 5%。这种情况下看带宽看不出问题但业务可能已经出现大量丢包和延迟。常用的实时工具还有nload eth0 iftop -i eth0nload提供带宽曲线iftop可以按连接查看流量来源和目的地址。8.2 检查网络重传与握手队列网络问题最常见的一种是带宽没有打满但接口响应变慢。这时候需要检查 TCP 层netstat -s | grep -i retrans如果重传率持续上升说明网络链路存在丢包常见原因包括内核缓冲区不足net.core.rmem_max和net.core.wmem_max设置过小。网卡队列溢出ethtool -S eth0中查看rx_dropped和rx_missed。突发流量超过网卡处理能力。查看 TCP 握手队列溢出情况ss -lnt输出中Send-Q和Recv-Q在监听状态下的含义不同对监听套接字Recv-Q表示当前已完成握手但尚未被应用 accept 的连接数如果持续增大说明应用 accept 速度跟不上Send-Q表示握手队列最大长度。如果这个值等于net.core.somaxconn并且持续满说明并发连接涌入太快。9. 综合实战一次多指标联动定位瓶颈的排查过程9.1 场景描述线上一个常规业务接口出现延迟告警从原本平均 80ms 上升到 1.5s。初步怀疑是数据库慢查询但 DBA 反馈数据库没有异常。这时需要系统性地把六类指标都拉出来对比。9.2 监控数据采集在告警时间段收集以下数据top -b -n 2 -d 3 top.log vmstat 1 5 vmstat.log pidstat -w 1 5 ctx.log iostat -x 1 5 iostat.log sar -n DEV 1 5 network.log如果机器带有 GPU还需要观察训练任务或推理服务的 GPU 利用率。9.3 数据分析与结论推断假设采集到的数据呈现以下特征指标数值/状态初步判断CPUus75%计算负载较高CPUwa1%大概率不是磁盘等待上下文切换45000 次/秒明显偏高8 核机器单核约 5600 次/秒非自愿切换28000 次/秒线程被频繁抢占内存 available20GB内存充足磁盘 %util12%磁盘压力不大网络 PPS60000 包/秒中高流量但未打满只看 CPU 和磁盘会得出“CPU 计算压力大”的结论。但结合上下文切换后真正的疑点是非自愿切换占比过高说明系统中有大量线程在竞争 CPU 时间片。线程数量多而且每个线程都在抢 CPU才会导致这种状态。继续使用下列命令确认进程线程数ps -eLf | wc -l如果线程数达到数千而 CPU 核心只有 8 核那么线程调度必然带来大量切换开销。这种情况下业务接口的大部分时间消耗在线程切换和等待 CPU 时间片上而不是在真正执行业务逻辑。9.4 解决方案与验证针对线程过多导致上下文切换过高的问题优化方向优先选择调整应用线程池大小将核心线程数从 200 调整为 64。将最大线程数从 2000 调整为 200。配合队列容量控制避免任务无线排队。调整后重新采集数据上下文切换从 45000 次/秒下降到 12000 次/秒接口延迟恢复到 90ms 左右。这里的关键启发是如果一开始只盯着 CPU 使用率可能会增加机器配置而不是调整线程池问题没有解决还白白增加成本。把 CPU、上下文切换和线程数放在一起看才能找到性价比最高的优化点。10. 常见问题与排查清单10.1 常见问题速查表问题现象常见原因解决思路GPU 利用率低训练速度慢CPU 数据加载成为瓶颈优化 DataLoader 的 num_workers检查磁盘读取速度GPU 利用率低显存占满模型过大或 batch size 过大降低 batch size开启梯度累积CPU 使用率高但业务不复杂死循环、正则回溯、GC 频繁抓取线程栈/函数调用栈定位热点上下文切换高且自愿切换多锁竞争、线程 sleep 频繁减少锁粒度优化任务队列模型上下文切换高且非自愿切换多线程数远超核心数调整线程池大小available 内存低但 RSS 不高页缓存占用量大确认是否有大量文件读操作必要时调适 vm.dirty_ratio应用报 OOM 但系统内存充足容器/cgroup 内存限制查看 cgroup 内存限制并合理配置磁盘 %util 高await 高磁盘达到性能上限迁移到 SSD、减少随机小 I/O、增加副本磁盘 %util 不高但应用慢文件系统锁、日志 fsync 频繁调整日志刷盘策略检查文件系统状态带宽不高但延迟升高TCP 重传、握手队列满检查重传率、somaxconn、rmem/wmemPPS 高且软中断集中在单核网卡多队列未开启开启 RSS设置中断亲和性10.2 排查清单现场问题发生时强烈的建议按以下顺序保存快照而不是先重启机器[ ] 保存top -b -n 3输出确认 CPU 和负载情况。[ ] 保存vmstat 2 10输出确认上下文切换和 I/O 等待。[ ] 保存iostat -x 2 10确认磁盘压力。[ ] 保存sar -n DEV 2 10和ss -s确认网络状态。[ ] 保存free -h和cat /proc/meminfo确认内存分布。[ ] 如果涉及 GPU执行nvidia-smi dmon -s puct -d 1持续采集。[ ] 记录应用日志中最近 10 分钟的异常。[ ] 保存dmesg -T | tail -100排查内核级报错和 OOM。有了这些数据再结合上面六类指标的分析方法就能逐步缩小范围最终定位到具体进程和代码层面。11. 最佳实践与工程建议11.1 建立持续监控与历史数据基线临时执行top和vmstat只能看到当下状态无法反映业务高峰期的真实水位。建议在每台机器上开启 sysstat 历史采集同时配置 Prometheus node_exporter Grafana 这类开源监控方案。node_exporter 默认就暴露了 CPU、内存、磁盘、网络等指标配合告警规则可以及时发现指标异常。对于 GPU 机器可以部署 DCGM ExporterNVIDIA 官方出品暴露 GPU 利用率、显存使用、温度、功耗等指标到 Prometheus。监控数据的另一层价值是建立基线。只有知道正常业务高峰时 CPU 是多少、上下文切换是多少、磁盘 await 是多少才能给告警阈值设置合理参数。没有基线的告警要么频繁误报要么错过真正的异常。11.2 配置指标告警时使用组合条件单指标告警容易误判。举例来说CPU 使用率高并不一定代表需要扩容可能只是定时任务在跑上下文切换高但 CPU 和业务延迟都正常可能只是并发量正常不必报警。更具参考价值的告警规则是基于组合条件的比如CPUiowait大于 20% 且磁盘avgqu-sz大于核数。上下文切换大于基线 2 倍 且 请求错误率上升。GPU 利用率低于 30% 且 训练作业未结束。告警的目的不是暴露所有指标而是在影响业务之前提前预警。11.3 重视资源隔离与容量规划多租户场景下容器和虚拟机之间要配置合理的资源限制。Kubernetes 中为 Pod 设置 CPU request/limit、内存 limit并用ResourceQuota限制 namespace 总用量可以避免单个应用耗尽宿主机资源。GPU 场景则需要使用 NVIDIA Device Plugin 或 MIG 功能做 GPU 资源隔离避免多个任务争抢显存和算力。容量规划方面建议每个月至少复盘一次核心服务的资源水位包括 CPU、内存、磁盘、网络和 GPU 的峰值与趋势。尤其是日志量增长比较快的服务磁盘空间很容易被撑满模型训练场景中数据集规模扩大和模型参数量增大都会直接影响显存和磁盘需求。11.4 定期做全链路压测和故障演练性能监控的最终目标不是“能看到指标”而是“能在问题影响用户前提前发现并处置”。建议每季度做一次核心链路压力测试模拟峰值流量下各资源的消耗情况提前发现 CPU 上下文切换过高、数据库连接数打满、网络连接队列溢出等潜力问题。压测后不要只保留结果要把问题修复记录和监控阈值调整记录都保留下来作为下一轮监控优化的输入。对于需要长期运行的训练任务建议增加 GPU 利用率、数据加载耗时、显存增长趋势的自动化监控并配置任务级探活。训练中断后自动恢复checkpoint 重启比人工发现再处理可靠得多。11.5 从指标到行动的闭环思维在系统监控这个领域指标本身不产生价值基于指标的行动才产生价值。建议团队内部建立一套简单的处置流程收到告警 - 拉取时间窗口内全部指标 - 判断瓶颈类型 - 执行对应处置动作 - 记录复盘结论 - 更新基线或告警规则。这个闭环跑顺之后同样的故障往往能被提前拦截或者在几分钟内定位而不是靠重启机器或盲目扩容来解决问题。