真实环境下大内存Go服务性能优化一例

本文转载自微信公众号「董泽润的技术笔记」，作者董泽润。转载本文请联系董泽润的技术笔记公众号。

创新互联-专业网站定制、快速模板网站建设、高性价比井陉网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式井陉网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖井陉地区。费用合理售后完善，十余年实体公司更值得信赖。

本文是在上家的 case, 以前很多人在公开大会上拿该案例做分享，所以觉得有印象的同学勿喷，虽然冷饭，但是原创，而且干货十足 ^_^

有时大家很不理解的现象，明明 call RPC 时设置了超时时间 timeout, 但是 Grafna 看到 P99 latency 很高，why ???

不要犹豫，要么是 timeout 设置不合理，比如只设置了单次 socket timeout, 并没有设置 circuit breaker 外层超时。参考你真的了解 timeout 嘛[1]

还有一种情况就是 GC 在捣乱，我们知道 Go GC 使用三色标记法，在 GC 压力大时用户态 goroutine 是要 assit 协助标记对象的，同时 GC STW 时间如果非常高，那么业务看起来 latency 就会得比 timeout 大很多

毛刺

该服务使用 go1.7, 需要加载海量的机器学习词表，标准的 Go 大内存服务，优化前表现为 latency 非常高

可以看到最大的己经到了 2s

同时查看 GC PauseNS 也非常可怕，基本接近 1s, 服务处理不可用状态

Pprof

如何开启 pprof 这里就不写了，网上有很多，大家可以自行查看

 
 
 
 
  
  
  
  go tool pprof bin/dupsdc http://127.0.0.1:6060/debug/pprof/profile

可以看到 runtime.greyobject, runtime.mallocgc, runtime.heapBitsForObject, runtime.scanobject, runtime.memmove 就些与 GC 相关的占据了 CPU 消耗的 TOP 6

 
 
 
 
  
  
  
  go tool pprof -inuse_objects http://127.0.0.1:6060/debug/pprof/heap

再查看下常驻对像个数，发现 1kw 常驻内存对像(现在来看很小了，不多)，这些都是词表加载的小对像

优化对像

词表主要使用两种类型，map[int64][]float32 和 map[string]int

让我们看一下三色标记，本质是递归扫描所有的指针类型，遍历确定有没有被引用

那么问题来了，什么是指针类型呢???所有显示 *T 以及内部有 pointer 的对像都是指针类型，比如 map[int64][]float32 因为值是 slice, 内部包含了指针，如果 map 有 1kw 个元素，那么 GC 也要递归所描所有 key/value

了解这些，优化方法就来了，把 map[int64][]float32 变成 map[int64][6]float32, 这里 slice 变成 6 个元素的数组，业务可以接受

同时把 map[string]int 里的 key 由 string 类型换成 int 枚举值

优化效果

上线后优化效果很明显

可以看到，常驻内存对像由 1kw 降低到 200w

同时 cpu pprof 也能看到，排名第一的是 syscall, GC 相关的己经降低很多

查看 Grafana 外围 IO latency 降低非常明显。整体优化效果不错

例外

这里也有例外，比如 map 内部的实现，如果 key/value 值类型大小超过 128 字节，就会退化成指针

 
 
 
 
  
  
  
  // Builds a type representing a Bucket structure for
  
  
  
  // the given map type. This type is not visible to users -
  
  
  
  // we include only enough information to generate a correct GC
  
  
  
  // program for it.
  
  
  
  // Make sure this stays in sync with runtime/map.go.
  
  
  
  const (
  
  
  
   BUCKETSIZE  = 8
  
  
  
   MAXKEYSIZE  = 128
  
  
  
   MAXELEMSIZE = 128
  
  
  
  )

 
 
 
 
  
  
  
  // bmap makes the map bucket type given the type of the map.
  
  
  
  func bmap(t *types.Type) *types.Type {
  
  
  
   if t.MapType().Bucket != nil {
  
  
  
    return t.MapType().Bucket
  
  
  
   }
  
  
  
  
  
  
  
   bucket := types.New(TSTRUCT)
  
  
  
   keytype := t.Key()
  
  
  
   elemtype := t.Elem()
  
  
  
   dowidth(keytype)
  
  
  
   dowidth(elemtype)
  
  
  
   if keytype.Width > MAXKEYSIZE {
  
  
  
    keytype = types.NewPtr(keytype)
  
  
  
   }
  
  
  
   if elemtype.Width > MAXELEMSIZE {
  
  
  
    elemtype = types.NewPtr(elemtype)
  
  
  
   }
  
  
  
  
  
  
  
   field := make([]*types.Field, 0, 5)
  
  
  
    ......
  
  
  
  }

思考

Go 每个版本性能都会提升很多，go1.7 1kw 对像服务压力非常大，但是我司现在 go1.15 2kw 对像未优化也毫无压力

Go 在吞吐量方面优化非常显著。还是那句话，本文只做为 GC 性能分析参考，不要提前优化

另外一方面也说明，Go 三色标记并不适合所有场景，本次分享的大词表常驻内存就是一个典型：

很明显的 old objects, 不需要 GC 每次都扫描，这里羡慕 java 的分代 GC

文章标题：真实环境下大内存Go服务性能优化一例
转载来源：http://www.stwzsj.com/qtweb/news14/16714.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容