先给结论：线上只能做受控采样
Nsight Systems 可以用于定位 CPU、GPU、CUDA API、操作系统调度等时间线问题，但生产环境不适合长期全量追踪。正确做法是把它当作短时、定点、可回退的诊断工具：先限定追踪窗口，再限定采样比例和采集字段，最后用业务指标确认开销是否可接受。全量长期追踪会改变负载行为，并产生难以管理的采集数据，这一点必须作为默认失败边界处理。
适用条件要先说清楚
适合线上采样的场景通常有明确症状，例如 GPU 利用率异常波动、推理延迟长尾、CUDA 调用阻塞、CPU 线程调度争用，或者某个版本上线后吞吐下降。它不适合替代持续监控，也不适合在未知高峰期对全部实例开启。Nsight Systems 的能力范围和命令行选项应按 Nsight Systems User Guide 复核，尤其是目标平台、可追踪事件、导出格式和版本差异。
追踪窗口必须比问题更窄
窗口设计的原则是覆盖一次可复现的异常，而不是覆盖整段业务周期。可以先从预发布或单个低风险实例开始，用几十秒级别的窗口验证是否能看到关键时间线，再根据问题持续时间调整。窗口应绑定触发条件，例如特定模型、特定接口、特定批大小、特定队列积压状态，而不是简单按固定时间轮询全量开启。若问题只在高峰出现，也应选择少量实例短时采样，并避开容量已经紧张的节点。
采样比例按风险分层
生产采样比例不应从“多少更完整”出发，而应从“多少不会破坏服务”出发。一个可执行分层是：先在测试环境完整复现；再在灰度实例开启短窗口；确认无明显扰动后，选择极少量生产实例按需触发；只有在事件严重且已有容量冗余时，才扩大覆盖范围。比例控制还包括进程范围、线程范围、事件类别和导出内容范围。对容器化环境，还要确认目标进程权限、挂载路径、时钟同步和采集文件写入位置。
开销控制不是事后补救
追踪会引入额外记录、缓冲、同步和文件写入成本，具体影响与硬件、驱动、CUDA 版本、事件类型、负载形态和采集时长有关，不能套用固定数字。应在开启前记录基线：请求延迟、吞吐、错误率、GPU 利用率、显存占用、CPU 使用率、上下文切换、磁盘写入和采集文件大小。开启后持续对比这些指标，一旦超过预设阈值就停止采样。涉及 CUDA 运行时和底层活动记录时，还应参考 CUPTI Documentation 理解相关接口与活动采集边界。
隐私边界要写进执行步骤
性能时间线本身也可能暴露业务信息，例如进程名、命令行参数、路径、容器名、模型文件名、用户标识、请求模式或内部服务拓扑。线上采样前应明确哪些字段可以采集、哪些路径不能落盘、采集文件保存多久、谁可以下载和分析。不要把原始追踪文件直接发到无访问控制的协作空间。必要时先在隔离环境复现，或对文件名、路径和参数做最小化处理。若无法确认采集内容是否含敏感信息，应暂停生产采样，改用聚合指标或脱敏后的离线复现。
推荐执行流程
- 确认问题假设：写清楚要验证的是 GPU 空闲、API 阻塞、线程等待还是 I/O 抖动。
- 建立基线：采集未开启 Nsight Systems 时的业务和系统指标。
- 限定目标：只选择必要实例、进程、时间窗口和事件类别。
- 先小流量验证：在灰度或单实例上运行一次短窗口采样。
- 观察开销：对比延迟、吞吐、错误率、CPU、GPU、磁盘写入和文件大小。
- 导出分析：只保留定位所需文件，按访问权限存放。
- 形成结论：把时间线证据与业务指标对应，避免只凭单次截图判断。
验证指标和停止条件
一次有效采样至少应回答三个问题：异常是否在窗口内出现，时间线是否能解释异常，采样本身是否显著改变负载。建议把停止条件提前写入变更单，例如延迟超过阈值、错误率升高、磁盘空间快速下降、采集文件增长失控、GPU 任务排队恶化，或值班人员无法确认隐私边界。若采样后只得到巨大文件却没有明确问题片段，应缩短窗口、减少事件类别，而不是继续延长追踪。
回退路径要可立即执行
回退不应依赖人工临场判断。执行前应准备关闭命令、进程清理方式、采集目录清理策略和监控确认步骤。若采样引入扰动，立即停止追踪，保留必要日志和指标快照，恢复实例到采样前配置；若节点状态已异常，应从负载均衡摘除或替换实例。后续再用离线复现、压测环境或更窄的事件范围重新验证。生产采样的价值在于提供足够证据，而不是追求一次抓全。
WeChat
Profile