Go服务器性能调优：避坑选型，QPS翻倍实战

　　2025年8月那会儿，我被拉去救一个Go服务器的火场——老板说QPS卡在八千，再冲不上去就砍预算。我原以为就是个常规的压测调参，结果到了机房才发现，这哪是调优，分明是拆炸弹。运维小王蹲在角落啃煎饼，油渍蹭在服务器日志本上，抬头跟我说：“哥，这机器从早上就开始嚎，像被踩了尾巴的猫。”我凑近一听，风扇转得跟电钻似的，CPU温度表直接飙红——这哪是性能问题，这是散热系统先阵亡了。

　　第一坑是选型。老板拍脑袋说“用最新版Go”，我翻了下监控，发现旧版1.18的GC停顿反而更短。测试组小李举着压测报告冲进来：“哥，1.21的Pacer算法在高并发下会抽风！”我盯着他手里的数据，发现QPS曲线像心电图——每三分钟就抖一次。后来查了源码，原来是新版本默认启用了“透明巨页”，这玩意儿在内存碎片多的机器上，比老版本还慢二十个百分点。最后我们硬是把Go降级回1.18，老板在群里骂“逆版本而行”，可压测结果出来，QPS直接涨了三千五——他闭嘴了，但没道歉。

　　那天下午下暴雨，机房窗户漏风，我裹着运维的旧工装改配置。小王蹲在旁边修风扇，螺丝刀掉地上叮当响，他捡起来说：“哥，这机器以前跑Java的，JVM参数全照搬过来了。”我差点没喷出来——Go的GC和JVM能一样吗？翻出启动脚本一看，GOGC=100，这哪是调优，这是自杀。改成GOGC=200后，QPS又涨了八百，但内存占用翻了一倍。老板在监控大屏前跳脚：“内存超了！超了！”我指着曲线说：“您看，QPS也超了。”他沉默了三秒，说：“那…再加点机器？”

　　第二坑是连接池。我们用的MySQL，原配置max_connections=200，结果压测到五千QPS时，数据库开始报“Too many connections”。测试组小张抱着笔记本冲进来：“哥，我查了，Go的database/sql默认连接池是无限增长的！”我盯着他的屏幕，发现连接数在压测时像火箭一样往上窜，最后卡在两千四，数据库直接宕机。后来我们手动设置了MaxOpenConns=100，MaxIdleConns=50，QPS没降，但数据库稳了。老板在群里发了个“6”，我回了个“？”，他没再说话。

　　中间我出去抽了根烟，回来发现小王在改Nginx配置。他指着屏幕说：“哥，我把worker_connections从512调到2048了。”我差点没把烟头咽下去——这机器总共才四核，每个核的线程数调这么高，上下文切换能把你CPU榨干。果然，改完后QPS掉了五百，老板在监控前喊：“怎么回事？！”我让他把worker_connections改回1024，又调了worker_processes=auto，QPS才慢慢爬回来。小王挠头：“哥，这Nginx参数咋比Go还难调？”我拍了拍他肩膀：“因为Go至少有源码，Nginx…你得靠经验。”

　　最离谱的是日志。原配置是每条请求都写日志，压测时磁盘IO直接拉满。我让小李把日志级别改成Error，结果QPS又涨了一千二。老板在群里问：“怎么突然涨了？”我回：“因为之前全在写日志，没空处理请求。”他发了个“哦”，然后转发了篇《高并发系统日志最佳实践》——我点开一看，作者写的和我们现在做的完全相反。小王在旁边笑：“哥，这老板是不是被割韭菜了？”我瞪他一眼：“闭嘴，干活。”

　　最后QPS冲到一万二，老板在庆功宴上举杯：“多亏大家努力！”我低头吃菜，没接话。小王凑过来小声说：“哥，其实最开始那台机器，风扇是好的，是我煎饼油滴进去才坏的。”我差点把可乐喷出来——合着我们调了半个月的优，源头是个煎饼？他挠头：“那…要不我请你吃个新的？”我摆摆手：“算了，下次记得别在机房吃。”

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!