小米Talos GC性能调优实践

最新推荐文章于 2021-12-01 03:15:00 发布

小米技术

最新推荐文章于 2021-12-01 03:15:00 发布

阅读量2.1k

点赞数 1

本文链接：https://blog.csdn.net/pengzhouzhou/article/details/103917893

版权

本文讲述了关于Talos GC性能调优的实践过程。

往期文章回顾：小米数据收集利器:AgentSource

背景

Talos作为小米自研的消息队列，在公司内部已经有了较为广泛的应用，支持了多个重点的离线和在线业务，随之而来的是业务对性能更高的要求。而对消息队列来说，最关键的性能指标不外乎吞吐和延时。对于吞吐，因为Talos的设计思想就是面向吞吐型的消息队列，再加上前文(Talos网卡负载优化：基于个性化一致性哈希的负载均衡)中所述Talos对网卡负载的优化，吞吐性能已经不是Talos的瓶颈。在高吞吐的场景下，Talos仍待解决的是GC问题对延时的影响，前文（万亿级消息背后：小米在消息队列的实践）中介绍了Talos在GC问题上经历的三个阶段，本文将详细介绍各阶段遇到的问题和解法。

>>>>
CMS中的重要概念

1.分代回收

目前主流的垃圾回收都采用“分代回收“的思路，CMS虽然是一款针对老年代的垃圾收集器，但仍免不了和年轻代打交道，因此这里简单描述一下”分代回收“思想。

年轻代：包含一个Eden区和两个Survivor区，其中Eden区是对象产生的区域，Survivor区主要存储存活着但还不能晋升到老年代的对象

老年代：存放常驻内存对象的区域

分代回收：当Eden区满时，会发生一次年轻代回收（Young GC），将仍存活的对象复制到一个Survivor区，当这个Survivor区满时，存活但没有达到晋升条件的对象全部被复制到另一个Survivor区中，达到晋升条件的对象则被放入老年代；当老年代空间使用率达到阈值，触发一次老年代回收（Old GC），将老年代中已经”死掉“的对象清理掉。需要注意的是，常说的Full GC是包含年轻代回收和老年代回收的。

2. CMS原理简述

CMS(Concurrent Mark Sweep)，是一种以牺牲吞吐量为代价来缩短应用停顿时间的、垃圾收集过程中的大部分线程可以和应用线程并发执行的、面向老年代的、采用并发标记-清除算法的垃圾收集器，一次CMS GC的主要过程如下（灰色代表应用线程，黑色代表GC线程，其中Initial-mark和Remark阶段会暂停应用进程的执行，称为Stop the world(STW)）：

Initial-mark：标记老年代中所有能被年轻代和GC Root直接引用的对象（GC Root可以理解为本次GC时肯定不会被回收的部分对象，例如静态变量）

Marking/Pre-cleaning：Marking表示在应用程序运行的同时遍历Initial-mark阶段标记出来的对象，并递归扫描这些对象可达的所有对象（标记出老年代中所有存活的对象）；Pre-cleaning表示清理应用程序并发执行时出现的引用关系变化，例如刚晋升的对象和直接分配在老年代的对象

Remark：暂停所有应用线程，重新扫描堆中的对象，在开始清理之前保持标记的正确性，查找在并发标记阶段漏掉的对象

Concurrent Sweeping：回收被标记为不可达的对象，这一阶段存活的对象并没有发生移动

3.内存碎片问题

了解”标记-清除“算法的同学应该知道这种方法将会产生大量的内存碎片，这是因为：CMS将内存空间划分成一个个的网格，内存是连续分配的，但回收时只收集”死亡“的对象，不关心仍存活的对象。因此当应用程序执行一段时间后，必然会出现大量不连续的空闲内存碎片，导致老年代虽然还有很大剩余空间，但无法找到足够大的连续空间来分配申请的对象，触发Full GC(Promotion failed)

4.Floating Garbage 问题

在并发清理阶段，用户线程仍在运行，如果产生新的垃圾，在此次GC中无法得到处理，只能等到下次清理，这些对象称为Floating Garbage。当Floating Garbage过多导致内存空间不足，那么CMS GC过程中就会出现Full GC（Concurrent Mode Failure）