把最大线程数从 50 调到 400 想扛住高峰，QPS 反而从 3200 掉到 2400，vmstat 里 cs 一列每秒 18 万，us 和 sy 都在涨。日志里能对上时间点，这种反而好排。
线程数远超 CPU 能并行处理的数量，调度器大部分时间在保存和恢复上下文，真正干活的时间被切碎。锁竞争和缓存失效也跟着放大。这一点先确认清楚，后面就不用反复试。
vmstat 1 5 pidstat -w -p 1 1 5
「上下文切换开销」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
处理上按这个顺序：先用 vmstat 1 看 cs 和 sy 的占比 确认瓶颈在调度；按 CPU 密集和 IO 等待比例重算线程数 别靠拍脑袋；逐步回调到 100 到 150 每次压测记录 QPS；同时看 load 和 run queue 确认不是队列长度在骗人。
结果对不对很好判断，cs 降到每秒 3 万以内，QPS 回到 3000 以上，sy 占比低于 20%。