建立Linux服务性能基线的核心是采集稳定负载下的典型指标作为异常识别和容量规划的参照标准，需明确业务高峰期请求类型、典型用户行为路径及数据规模，如电商订单服务基于每秒200次下单请求、响应时间≤150ms、数据库写入延迟等。
建立Linux服务性能基线，核心是采集稳定负载下的典型指标，并用它作为后续异常识别和容量规划的参照标准。不是测一次峰值，而是找“常态中的健康值”。
明确服务场景与负载特征
同一服务在不同使用模式下表现差异极大。需先定义：
• 业务高峰期的请求类型（如HTTP API调用、数据库批量写入、文件上传并发数）
• 典型用户行为路径（如登录→查订单→下单→支付）
• 数据规模（单次查询平均返回记录数、日均新增数据量）
例如：一个电商订单服务，基线应基于“每秒200次下单请求+平均响应时间≤150ms+数据库写入延迟
选择可量化、可观测的核心指标
避免堆砌指标，聚焦影响用户体验和系统稳定的最小关键集：
• 应用层：请求成功率、P95响应延迟、吞吐量（QPS/TPS）
• 系统层：CPU平均负载（非单核使用率）、内存可用率（非cached/buffer占用）、磁盘I/O等待时长（await）、网络重传率（netstat -s | grep "retransmitted"）
• 依赖层：下游API平均耗时、数据库连接池等待数、缓存命中率
所有指标必须能通过Prometheus+Exporter、sysstat、atop等标准工具持续采集，且时间精度不低于10秒。
执行可控、可复现的基线采集
基线不是上线前测一次就完事，而需满足三个条件：
• 环境纯净：关闭非必要后台任务，禁用自动更新，确保内核参数、服务配置与生产一致
• 负载稳定：使用wrk、go-wrk或自研流量脚本，以恒定RPS持续运行≥30分钟，跳过前5分钟预热期再采样
• 多轮验证：至少连续3天在相同时间段采集，剔除单日异常毛刺，取中位数而非平均值（防离群点干扰）
结果输出为带时间戳的CSV或直接存入TSDB，标注清楚环境版本、内核参数、JVM/Python启动参数等上下文。
建立动态基线与偏差告警机制
静态基线会过期。建议：
• 按周滚动更新：用最近7天同时间段的P95延迟中位数生成新基线值
• 设置合理浮动区间：如CPU负载基线为1.2，则告警阈值设为1.2×1.5=1.8，避免夜间低峰期误报
• 关联指标交叉验证：当响应延迟上升但CPU未涨，优先查GC日志或数据库锁；若延迟与磁盘await同步升高，聚焦IO调度或存储性能
基线本身要版本化管理，每次变更需记录原因（如“因引入新索引，DB查询延迟基线下调22%”）。
