高频 golang 服务接口超时排查&性能调优

桔妹导读：业务中超时抖动是大家平时比较容易遇到的一种技术问题，本文详细记录了一次线上容器中高频 go 服务超时的排查过程。本文可以给大家提供查服务业务超时问题的一些思路，理解为什么 go 服务会获取错 cpu 核数，了解获取宿主 cpu 核数会有多大影响并怎样最小成本避开。

0. 

目录

---

1. 背景

2. 解决思路

3. 现场分析

        网络分析

        负载分析

        redis sdk 问题排查

        runtime 问题排查及优化

        抓trace ，查看调用栈

4. 原理分析

5. 总结

1. 

背景

---

最近，策略组同学反馈有个服务上线后 redis 超时非常严重，严重到什么地步呢，内网读写redis 毛刺超过100ms！ 而且不是随机出现，非常多，而且均匀，导致整个接口超时严重。因为用的 redis 库是由我们稳定性与业务中间件组维护，所以任务落我们组小伙伴头上了。

 

这个项目有非常复杂的业务逻辑，然后要求接口在100 ms 左右能返回。这个服务有密集型 io（调度问题）+定时任务（cpu问题）+常驻内存 cache（gc问题）。频繁访问 redis，在定时逻辑中，业务逻辑一个 request 可能达到上千次 redis Hmget/Get (先不讨论合理性)。 复杂业务给问题排查带来比较多干扰因素，这些因素都可能导致抖动。

 

go version : 1.8，机器是8核+16G 容器，没有开 runtime 监控，redis 的同事初步反馈没有 slowlog。因为rd 也追了很久，到我们这边来的时候，redis 的超时指标监控已经给我们加了，每个key 的查询都会打印日志方便debug。

 

redis get 接口的耗时监控显示如下，因为高频请求，大部分耗时是小于10ms 的，但是这毛刺看着非常严重，是不可忍受了。

系统cpu问题比较严重，抖动非常大，内存并没有太大问题，但是占用有点大。因为用了local-cache，也可能引起 gc 问题。

 

  

因为没有加 runtime 监控，其他信息暂不可知。

2. 

解决思路

---

因为追查接口毛刺比较复杂，我们的原则是不影响业务的情况下，尽量少上线的将业务问题解决。

 

第一、首先排查是不是网络问题，查一段时间的 redis slowlog（slowlog 最直接简单）；

 

第二、 本地抓包，看日志中 redis 的 get key 网络耗时跟日志的时间是否对的上；

 

第三、查机器负载，是否对的上毛刺时间（弹性云机器，宿主机情况比较复杂）；

 

第四、查 redis sdk，这库我们维护的，看源码，看实时栈，看是否有阻塞（sdk 用了pool，pool 逻辑是否可能造成阻塞）；

 

第五、查看 runtime 监控，看是否有协程暴增，看 gc stw 时间是否影响 redis（go 版本有点低，同时内存占用大）；

 

第六、抓 trace ，看调度时间和调度时机是否有问题（并发协程数，GOMAXPROCS cpu负载都会影响