结论先行：国产系统承载核心业务之后，性能问题多半不出在系统本身，而出在「照搬了旧环境的经验值」。可行动的顺序是三步：先按业务画像取一份真实负载下的基线，再把瓶颈归到资源争抢、IO 路径、内核参数三类分别处理，每次只动一组参数并做前后对比。没有基线、没有回归对比的调优，只是把不确定性换了个位置。
「装上了」和「跑得好」是两件事
迁移阶段关注的重点通常是能不能装、能不能启动、业务能不能连上，性能则是靠默认参数先跑起来。问题出在下一步：旧环境积累的那套经验值被直接搬了过来。调度策略、内存回收、文件系统挂载选项、网络参数，这些默认值面向的都是通用场景，换一套底层之后未必仍然合适。
表现也很典型：压测能过，业务高峰扛不住；单机跑起来正常，进了集群互相拖慢；白天看不出问题，跑批时段集中暴露。这类现象靠「再加点资源」通常只能缓解，找不到真原因。
先定基线，再谈调优
调优之前必须先有一份基线，否则改完也不知道好在哪。基线要取三类数据：
- 容量水位。CPU、内存、磁盘 IO、连接数、队列长度——看的是余量还有多少。
- 时延分布。不只看平均值，要看高分位。平均值好看、高分位难看，是典型的排队或争抢问题。
- 错误与重试。超时、重试、失败次数的变化，往往比资源水位更早反映问题。
取基线有个前提：必须在业务真实负载下取，空载跑分说明不了问题。可以先用系统自带的体检与调优工具把当前水位与偏离项算出来，避免凭感觉改参数。
三类瓶颈，处理方式不同
| 瓶颈类型 | 常见表现 | 优先采取的动作 |
|---|---|---|
| 资源争抢 | 多业务同机时互相拖慢，高峰时整体变慢 | 先做隔离与配额，再谈参数；改内核参数收益有限 |
| IO 与存储路径 | 写等待高、时延抖动，跑批时段明显 | 核对挂载选项、缓存策略、多路径与队列深度 |
| 内核与网络参数 | 连接建立慢、突发流量下丢包或超时 | 调整连接队列、超时与重传、内存回收策略，小步验证 |
顺序上建议先解决资源争抢，再处理 IO 路径，最后动内核参数。原因是前两类改的是「怎么分配」，影响可预期；最后一类改的是「系统怎么工作」，影响面大，必须在前面两类都稳定之后再动。
集群与批量场景要单独考虑
集群环境下有三个额外要求。其一，同一套参数不能同时适配数据库节点与应用节点，节点角色不同，侧重点不同。其二，批量下发要有模板、灰度批次与失败即停，不要一次全量推。其三，参数模板要版本化，能回答「什么时候改过什么」。
另外，下发前先备份配置基线，执行后核对结果。这一步看起来多余，但集群里一次错误下发的代价，往往比多花十分钟大得多。
怎么验证调优有效
判断标准只有一条：同一负载、同一观测口径下的前后对比。至少看三项——时延分位、吞吐、错误率，只改善平均值不算数。同时把变更记录留下来：改了什么、为什么改、谁批的、结果如何。这份记录在后续出现回归时，是最省时间的线索。
什么时候不该调
- 故障正在发生时不调参数。先止损、先恢复，调优放到稳定之后。
- 没有复现路径时不调。不能稳定复现的问题，调完也不知道是不是真的解决了。
- 涉及底层结构或驱动层的改动，按变更流程排窗口。这类改动需要停机或重启的，不要挤在业务高峰前做。
落地清单
- 按业务类型给核心系统做性能画像，标出高峰时段与峰值特征。
- 在真实负载下采集基线，覆盖容量水位、时延高分位与错误重试。
- 用系统自带的体检与调优工具输出当前水位与偏离项，形成待办清单。
- 把瓶颈归类到资源争抢、IO 路径、内核参数三类，按顺序处理。
- 涉及到内核参数时，每次只动一组，并准备回退路径。
- 集群批量下发使用模板与灰度批次，失败即停，下发前后各留一份基线。
- 每次调优做前后对比并归档记录，作为后续回归的参照。
国产化替代走到核心业务这一层，比拼的就不再是「能不能换」，而是「换完之后运维体系接不接得住」。奇摩在信创项目里通常把性能基线与调优能力清单和选型一起交付，而不是等上线之后再补。如果你希望先给现网做一轮性能基线盘点，欢迎 预约咨询。