Go服务器性能调优：16年日志工程师实战路径

　　去年6月份灰度那波，开发说Go服务CPU飚到90%肯定是日志打多了，我原以为他们又要甩锅，结果抓了三天pprof——好家伙，确实是日志模块在搞鬼。那会儿我正盯着测试机屏幕，键盘上空格键按下去不回弹，敲个命令得用指甲抠，隔壁工位小张桌上摆着三台手机，屏幕亮得跟圣诞树似的，他非说在测兼容性，我看就是刷短视频。

　　说回正题，Go的GC日志和业务日志混在一起打，每秒几万条，用例管理工具还在那转圈加载，我直接把日志级别从Debug切到Warn，CPU立马掉到30%。开发当时就懵了，说“这也能行？”，我说“你们写代码的时候没想过日志量级？”。后来查代码，发现他们用fmt.Sprintf拼日志字符串，每次GC都得扫一遍内存，我原以为这种低级错误早没人犯了，结果在边界条件分支里藏着——那分支线上根本没触发过，回归测试也没覆盖到。

　　会议室又被占了，我们蹲在走廊里复盘。开发说“要不把日志拆成两个协程写？”，我说“协程多了更麻烦，上次你们加协程导致panic的事忘了？”。最后决定用bufio.Writer缓冲，每100ms刷一次盘，结果测试机充电线不够长，我蹲在地上插线的时候突然想到——日志文件轮转的逻辑没改，缓冲期间文件被切了，数据全丢。小张在旁边喊“这算P0吗？”，我说“线上现在没报，但灰度环境肯定埋着雷”。

　　外卖凉透了，我边啃冷汉堡边看日志。发现个更离谱的事：他们用JSON.Marshal序列化日志字段，其中有个字段是[]byte类型，每次序列化都深拷贝，GC压力直接翻倍。我问开发“这字段是干嘛的？”，他说“备用字段，可能存二进制数据”，我说“可能？你们写代码全靠猜？”。他辩解“线上没复现过”，我指着监控图说“灰度环境流量是线上的1/10，等全量了你看CPU会不会爆”。

　　后来我们定了个规矩：日志字段必须显式定义类型，[]byte直接转base64字符串，禁止深拷贝。开发说“这样性能会降”，我说“降5%总比CPU 100%强”。改完冒烟测试，CPU稳在40%，但线上突然报了个偶现的日志错乱——后来查是缓冲区的并发写问题，开发说“你不是说协程多了麻烦吗？”，我白了他一眼“我说的是乱加协程，这种明确IO边界的场景不用协程才是傻”。

　　跑题说下测试机——公司那批老机器，SSD读写速度还没机械盘快，回归测试跑完要俩小时，有次我等得实在无聊，把白板上的数字擦了一半，写了个“求换新机”，结果第二天行政真的搬来两台，不过键盘还是那批不回弹的。说回日志，后来我们加了日志采样，流量高的时候只记10%的请求，开发又担心“丢失关键信息”，我说“关键信息走单独通道，别跟普通日志混”。他问“怎么定义关键？”，我说“线上报错的时候，你能在5秒内找到对应日志就是关键”。

　　最气人的是兼容性测试——开发改完日志模块，没通知测试环境升级Go版本，结果灰度环境用1.18，测试环境用1.16，某些新特性直接panic。小张提单的时候写“版本不一致”，开发反驳“1.16和1.18应该兼容啊”，我说“应该？你们写代码全靠应该？”。后来强制要求：日志相关改动必须同步升级Go版本，测试环境跑三遍基准测试再提审。

　　现在回头看，那波调优能成，真不是因为我们多厉害，是线上问题逼的——CPU 100%的时候，谁还管什么“优雅设计”，能跑起来就行。开发后来跟我说“早知道听你的，别用fmt.Sprintf”，我说“现在知道疼了？上次我说用strings.Builder，你们说‘麻烦’”。他挠头“那时候没想到流量会这么大”，我说“测试环境流量再高，能有线上1%？你们总说‘等线上再说’，等线上就是事故”。

文章配图，仅供参考

　　下一步打算把日志的链路追踪加上，开发说“这会影响性能”，我说“线上出问题的时候，你连日志都串不起来，性能再高有什么用？”。他没说话，低头改代码去了——我猜他键盘的空格键，也按不下去。

（编辑：站长网）

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