摘要：由此，对于这样的场景并不是很友好，那有没有能够精确控制内存，让其在的倍数时准确控制呢内存内存这就需要出场了。利用这个特性，就能保证在的一倍时才能被触发，这样就能够比较精准控制的触发时机。
关于 Go GC 优化的手段你知道的有哪些？比较常见的是通过调整 GC 的步调，以调整 GC 的触发频率。
这两种方式的原理和效果都是一样的，GOGC 默认值是 100，也就是下次 GC 触发的 heap 的大小是这次 GC 之后的 heap 的一倍。
我们都知道 GO 的 GC 是标记-清除方式，当 GC 会触发时全量遍历变量进行标记，当标记结束后执行清除，把标记为白色的对象执行垃圾回收。值得注意的是，这里的回收仅仅是标记内存可以返回给操作系统，并不是立即回收，这就是你看到 Go 应用 RSS 一直居高不下的原因。在整个垃圾回收过程中会暂停整个 Go 程序（STW），Go 垃圾回收的耗时还是主要取决于标记花费的时间的长短，清除过程是非常快的。
设置 GOGC 基本上我们比较常用的 Go GC 调优的方式，大部分情况下其实我们并不需要调整 GOGC 就可以，一方面是不涉及内存密集型的程序本身对内存敏感程度太低，另外就是 GOGC 这种设置比率的方式不精确，我们很难精确的控制我们想要的触发的垃圾回收的阈值。
GOGC 设置的非常小，会频繁触发 GC 导致太多无效的 CPU 浪费，反应到程序的表现就会特别明显。举个例子，对于 API 接口来说，导致的结果的就是接口周期性的耗时变化。这个时候你抓取 CPU profile 来看，大部分的耗时都集中在 GC 的相关处理上。
如上图，这是一次 prometheus 的查询操作，我们看到大部分的 CPU 都消耗在 GC 的操作上。这也是生产环境遇到的，由于 GOGC 设置的过小，导致过多的消耗都耗费在 GC 上。
对 API 接口耗时比较敏感的业务，由于这种接口一般情况下内存占用都比较低，因为 API 接口变量的生命周期都比较短，这个时候 GOGC 置默认值的时候，也可能也会遇到接口的周期性的耗时波动。这是为什么呢？
因为这种接口本身占用内存比较低，每次 GC 之后本身占的内存比较低，如果按照上次 GC 后的 heap 的一倍的 GC 步调来设置 GOGC 的话，这个阈值其实是很容易就能够触发，于是就很容出现接口因为 GC 的触发导致额外的消耗。
那如何调整呢？是不是把 GOGC 设置的越大越好呢？这样确实能够降低 GC 的触发频率，但是这个值需要设置特别大才有效果，GOGC 一般需要设置 2000 左右。这样带来的问题，GOGC 设置的过大，如果这些接口突然接受到一大波流量，由于长时间无法触发 GC 可能导致 OOM。
由此，GOGC 对于这样的场景并不是很友好，那有没有能够精确控制内存，让其在 10G 的倍数时准确控制 GC 呢？
这就需要 Go ballast 出场了。什么是 Go ballast，其实很简单就是初始化一个生命周期贯穿整个 Go 应用生命周期的超大 slice。
func main() { ballast := make([]byte, 10*1024*1024*1024) // 10G // do something runtime.KeepAlive(ballast)}上面的代码就初始化了一个 ballast，利用 runtime.KeepAlive 来保证 ballast 不会被 GC 给回收掉。
利用这个特性，就能保证 GC 在 10G 的一倍时才能被触发，这样就能够比较精准控制 GO GC 的触发时机。
这里你可能有一个疑问，这里初始化一个 10G 的数组，不就占用了 10 G 的物理内存呢？ 答案其实是不会的。
package mainimport ( "runtime" "math" "time")func main() { ballast := make([]byte, 10*1024*1024*1024) <-time.After(time.Duration(math.MaxInt64)) runtime.KeepAlive(ballast)}$ ps -eo pmem,comm,pid,maj_flt,min_flt,rss,vsz --sort -rss | numfmt --header --to=iec --field 5 | numfmt --header --from-unit=1024 --to=iec --field 6 | column -t | egrep "[t]est|[P]I"%MEM COMMAND PID MAJFL MINFL RSS VSZ0.1 test 12859 0 1.6K 344M 11530184这个结果是在 CentOS Linux release 7.9 验证的，我们看到占用的 RSS 真实的物理内存只有 344M，但是 VSZ 虚拟内存确实有 10G 的占用。
延伸一点，当怀疑我们的接口的耗时是由于 GC 的频繁触发引起的，我们需要怎么确定呢？首先你会想到周期性的抓取 pprof 的来分析，这种方案其实也可以，但是太麻烦了。其实可以根据 GC 的触发时间绘制这个曲线图，GC 的触发时间可以利用 runtime.Memstats 的 LastGC 来获取。
这张图相同的流量压力下，ballast 的表现明显偏好
本篇文章只是简单的阐述了 Go ballast 的使用，不过 Go ballast 是官方比较认可的方案，具体可以参见 issue 23044。很多开源程序，如 tidb，cortex 都实现了 go ballast，如果你的程序饱受 GOGC 的问题影响或者周期性的耗时不稳定，不妨尝试下 go ballast。
当然强烈推荐你看下twitch.tv 这篇文章，相信让你会对 GOGC 以及 ballast 的运用理解的更加透彻。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/123652.html
摘要：由于人们对图形的敏感度非常高，所以的渲染速度显得非常重要。中也提供了测试的方法，感兴趣的小伙伴可以尝试一下咯。过度绘制的问题。实在是要等到用到的时候加载，请给一个进度条，不要让用户干等着，也不知道什么时候结束而造成不好的用户体验。欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~ 本文由WeTest质量开放平台团队发表于云+社区专栏 一款app除了要有令人惊叹的功能和令人发指交互...
摘要：阿里云数据库提供了主从双副本主从单副本集群双副本等多样的产品供用户选择。最近阿里云又推出了的主从双副本实例，适用于缓存论坛加速数据库加速等，随着业务的发展用户还可以进一步扩容。 本文仅用于学习和交流目的，不得用于商业目的。非商业转载请注明作译者、出处，并保留本文的原始链接：http://www.ituring.com.cn/art... 访谈嘉宾： 本名郑明杭，现阿里云NoSQL数据库...
摘要：但是强迫症犯了，为了使得性能达到极致，再次进行了深度的优化。把移动中心设置在物体的重力中心，最为舒适。你可以狠狠的点击预览地址到此，组件，无论从性能，还是手感上来说，都已经相当的符合我们的需求了。 仓库地址：Dragact手感丝滑的拖拽布局组件 预览地址：支持手机端噢～ 上回我们说到，Dragact组件已经进行了一系列的性能优化，然而面对大量数据的时候，依旧比较吃力，让我们来看看，优化...
摘要：但是强迫症犯了，为了使得性能达到极致，再次进行了深度的优化。把移动中心设置在物体的重力中心，最为舒适。你可以狠狠的点击预览地址到此，组件，无论从性能，还是手感上来说，都已经相当的符合我们的需求了。 仓库地址：Dragact手感丝滑的拖拽布局组件 预览地址：支持手机端噢～ 上回我们说到，Dragact组件已经进行了一系列的性能优化，然而面对大量数据的时候，依旧比较吃力，让我们来看看，优化...
阅读 2314·2023-04-25 20:50
阅读 3702·2023-04-25 18:45
阅读 1369·2021-11-24 10:28
阅读 2089·2021-11-17 17:00
阅读 3059·2021-10-13 09:39
阅读 3206·2021-10-08 10:05
阅读 2869·2019-08-30 15:55
阅读 3383·2019-08-30 15:44
