Continuous profiling 拯救了 Victoria Metrics
即将退出历史的舞台 - 普罗米修斯
普罗米修斯(Prometheus)作为第一代的云原生监控系统，已经走过了整整 10 个年头，其丰富的功能特性、强大的数据模型等特点赢得了广大的用户，成为最主流的监控系统之一。
当今云原生的复杂度已今非昔比，分布式、海量数据、高可用等使 prometheus 越来越难以满足用户的需求。
我们同样面临这些问题，服务、指标、机器数量都在增长，而 prometheus 的单点化、低压缩率导致运维和资源成本不断增加；监控指标存储时间较短，需要久远历史数据进行分析时往往又爱莫能助，因此需要新一代的监控系统来替换现有的 prometheus。
时代的新秀 - 维多利亚
要引进新技术，最大的阻力莫过于历史的包袱。我们希望不影响用户体验及无缝整合现有基础设施，那无异于给一辆高速行驶的汽车换轮胎，所以新系统最好能兼容 prometheus 接口。
经过调研，最后决定使用维多利亚(Victoria Metrics)，其架构简单，可靠性高，在性能、成本、可扩展性方面表现出色，而且兼容 prometheus 接口。
现有 prometheus 集群规模，只保留 2 个月的数据，同样的机器下数量下，VM 能够保留 1 年，而且是双副本，收益非常明显。
吃螃蟹的代价 - 踩坑
经过一系列测试，我们对 VM(Victoria Metrics)的功能非常满意；但在做性能测试时，VM 就出现了严重的 CPU 抖动问题。
VM 集群中的 1 个节点的 CPU 利用率会偶发性地飚高到 100%，持续一段时间后又会自己恢复。
从下图中可以看出节点 13 CPU 突然增高到 97%，持续了 2 个多小时后恢复正常，其中读写 QPS 抖动非常严重，但是大多数时候持续时间较短。
节点 13 和其他节点的差异：13 的磁盘是 SSD，而其他节点是 HDD，高配机器反而出问题了？
image
普罗米修斯拯救维多利亚 - 用监控系统来分析监控系统的问题
我们使用 prometheus 收集 VM 的监控指标来进行分析，从监控大盘的来看，问题发现时：
CPU 利用率 涨到 100%
内存
index block 的 cache size 快速上涨
storage/inmemory 快速上涨
磁盘
写：写入量降低 CPU 就开始涨，写入量上涨 CPU 将降低了，延迟并没有变化
读：读取量降低（同时读 QPS 降低），延迟并没有变化
请求
读：返回的 blocks 数量上涨
写：QPS 降低，slow write 增加，并发写增加
什么是 index block？谁又是 storage/inmemory？很多指标都有异常，由于不了解 VM 原理，又怎么知道这些指标代表什么？
掀开引擎盖去了解每一个零件是不可能的，所以只能先从字面意思来推测这些指标的用途。index block 应该是索引块，可能代表读请求缓存的索引数据，而 storage/inmemory 应该是写入请求的内存缓冲块(很多存储引擎都这么命名，后面证明也确实如此)。
然而，监控指标的采集是有时间间隔的，指标的上涨非常快速，所以从监控大盘看不出其中的因果关系。
那么日志呢？系统、内核、服务日志都没有异常，只有问题发生时有写入和查询请求的超时日志，这说明不了什么。
外科手术刀 - 火焰图
表象看不出问题，那么就上剖析武器，火焰图。
使用 Go 自带的 pprof，通过 on-CPU 火焰图来分析耗时发生在哪里。
下图是节点 13 的火焰图：
image
正常节点的火焰图
image
通过对比正常节点火焰图可以看出，异常节点有不少比例的 CPU 时间消耗在几种锁的竞争上，还有不少是 Less 函数。
这。。。又能说明什么？SSD 机器的缓存有锁问题，HDD 机器就没有！
再结合之前监控系统的分析，发现其中干扰因素较多，无法分析具体因果关系，如：
出问题节点火焰图中没有写请求了，所以 cache 锁占比问题会被放大？
Cache 上涨和 vm_parts(inmemory)关系？抢 CPU？
Slow write 上涨，是磁盘写入慢导致还是由于 CPU 利用率太高导致写请求执行慢了？
阅读了一些源码以及翻阅 VM 的资料，有了一些基本的了解后，得出初步结论：
vm_parts(storage/inmemory)上涨：
导致读请求的 blocks 数量上涨，这是因果关系
导致内存挤压很多小 blocks，这就导致了 Less 函数调用次数上涨
Cache size 快速上涨，导致 cache 锁竞争
所以 cache 和 vm_parts(inmemory)上涨导致锁竞争。
积食，不是吃的太多，就是消化太慢 - 数据的积压
那什么原因导致 cache 和 vm_parts(inmemory)上涨呢？关系到写还是读？还是互相影响？为什么 SSD 的机器反而出问题？还是前期 cache 上涨导致的连锁反应？是否 cache 回收出问题了？
数量上涨，无外乎于要么是生产太快，要么是消费太慢导致的积压。
于是，添加了 cache 相关的监控，发现其回收等功能都没有问题。
再看看 vm_parts(inmemory)，13 是 SSD，应该读写更快才对，不过这是理论知识，通过对 SSD 进行了持续压测，发现磁盘性能较好，没有问题（用同步 IO，就能到 50MB/s 的写入速度，那么这块不是瓶颈），也没有抖动，所以不是消费问题。
那么很有可能就是生产太快导致积压，毕竟节点 13 是 SSD，读磁盘更快，创建 cache 更快也更多，所以更容易导致积压。当然，这只是推测，还需要更进一步分析。
阅读了一些源代码，没有找出问题，为了更高效排查问题，还是先求助于 VM 开发团队吧。
专家会诊 - 求助开发团队
开发团队给了排查的方向 Troubleshooting，根据文档里的步骤，逐一排查，没有发现任何问题。
但开发团队也根据我们的指标做了一版优化，都是集中在 Less 函数优化上，有改善但并没有解决问题。
后来，开发团队也给不出建议了。。。。。。
好奇心，先放一放 - 解决锁的问题
无法弄清楚根本原因，这样耗下去也不是办法，既然知道是锁问题，那么先解决问题再说。
优化 cache 导致的锁竞争问题，有 2 个方案
降低 cache 容量：这个方案会影响读性能
加大 cache 分片：加大分片能降低分片内的锁竞争，副作用是不利于 CPU 缓存，不过，总比降低 cache 容量要好。
于是，优化 index block cache，将分片数量从 CPUs * 16 逐渐调整到 CPUs * 32，压力加大到 2 倍，问题得到较大改善，但并不稳定。
再优化 fastcache（这块在火焰图中占比也不低）后，加大压力到 4 倍，CPU 问题没有再出现了。但是会有偶发性的小幅度的 QPS 抖动，如下图
image
精准武器 - Continuous profiling
由于这种抖动是随机的，且持续时间很短，出现问题再去 profiling 问题又恢复了，所以适合使用 continuous profiling 工具进行分析。
Pyroscope 是一款支持多语言的持续性能分析工具，对 go 语言支持较好，性能损耗较低，所以修改 vmstorage 代码，集成 pyroscope。
静静地等待问题发生。。。
image
问题再次发生了，查询 QPS 从 12:29:00 开始下降，但从延迟 QPS 上看，最近时间点 12:30:30 只有节点 3 的延迟 QPS 上涨了(前期猜测可能延迟 QPS 有一定滞后性，因为 VM 的指标更新是定时的)，貌似是节点 3 的问题？
通过 diff 来对比节点 3 和正常节点的 profiling 数据，如 on-CPU 火焰图，block duration，mutex duration 等看，节点 3 的指标都很正常！！！
有点怀疑人生了，难道哪个步骤出错了？
再逐一排查上面的分析，发现节点 3 的延迟 QPS 上涨其实和整体查询 QPS 下降是有 1 分钟的滞后的，这是个疑点。
打开延迟 QPS 指标，仔细查看每个节点后才发现节点 10 在 12:29:50 这个时间点缺少了数据，如下图
image
这个指标是 rate(vm_search_delays_total{}[60s])，1 分钟的聚合，所以其计算原理是 1 分钟内 (最后一个采样点 - 第一个采样点)/时间窗口，即 rate = Δvalue / Δtime。
但在采集数据缺失的情况下，
如果最后一个采样点或第一个采样点不存在怎么办？prometheus 直接将 rate 设置为 0
如果两个采样点都不存在呢？则 rate 设置为 null，那上图显示 12:29:50 时间点缺少的可能就是这个问题。
普罗米修斯的锅 - 数据缺失
通过 prometheus 接口拉取到 vm_search_delays_total 的原始采样数据，如下
在原始采样点中，从 12:28:50 到 12:29:50 都没有采样到数据，所以如果在 12:29:50 时间点进行 1 分钟内聚合，计算的 rate 点理论上应该是 null。
通过 Prometheus 接口计算 rate(vm_search_delays_total{}[60s]) ，按照 1 分钟内聚合运算 rate，返回的 rate 数据如下，在 12:29:50 时间点确实没有数据，那就是导致前面曲线缺失的原因了。
12:30:05 到 12:30:50 的 rate 仍然是 0，这是因为 1 分钟内聚合的 rate 计算中缺少第一个采样点数据，所以 rate=0，符合 Prometheus 的 rate 计算原理。
既然这样，那我们就将 1 分钟内聚合改成 2 分钟内聚合，就可以跨过缺少的采样点而避免 rate 是 null 的问题了。
将 promQL 改成 rate(vm_search_delays_total{}[120s])后，可以看到 12:30:05 时间点的 rate=315961170.1971519 了。
从图形上看，rate 曲线也“正常”了。至于 rate 的值，从公式计算应该是：(31172047293 - 0) / 120，应该是 259767060，而不是 315961170.1971519，这种偏差是由于选择的时间范围和采样点有偏差，而 Prometheus 会根据采样点计算斜率来弥补这种点位偏差导致的，故这里可以忽略。
image
通过曲线图发现，其实真正有问题的节点是 10，而不是 3！
找到病灶 - 限流
正确的曲线图
image
再次通过 pyroscope 持续进行分析，对正常和异常时段进行比较：
block duration：没有问题
mutex duration：merge 的锁占比较多（相对占比增加），但绝对值比较低。由于读写 QPS 占比发生了变化，所以并不能说明是 merge 的锁出现问题导致的。
on-CPU 火焰图：由于读写 QPS 占比变化，所以图中 flush 相关函数在火焰图中占比增加并不能说明问题。但是从其中一段函数 top 比对看，WaitIfNeed 函数占比增加较为明显，通过查看这一段代码发现了问题。
on-CPU 火焰图，flushPendingRows 占比增多，但不明显
image
mutex duration，mergeWorker 的占比明显增加，但是绝对值较小。
image
block duration， 比较起来也没有变化
image
然而比较正常与异常时段 top 函数，WaitIfNeed 增加！
image
分析 PaceLimiter 及相关的代码发现，Victoria Metrics 对任务做了优先级的区分，如果有高优先级任务存在，则低优先级任务需要等待。低优先级任务调用 WaitIfNeed 来检查是否需要等待。
这种实现并不合理：只要有一个高优先级任务在执行，其他所有低优先级任务都需要等待，写请求与合并任务属于高优先级任务，查询属于低优先级任务，所以只要有一个写入或者合并任务在执行，查询请求都必须等待，也就造成了查询延时增加。
所以之前从监控指标上来看，在 cpu，磁盘等都没有成为瓶颈的情况下，查询请求 QPS 会偶发性抖动。
结合之前的分析，所以可以得出结论：
节点 13 是 SSD 盘，其合并与写入等涉及到磁盘的操作更快，高优先级任务的执行也就更快，对查询请求的阻塞也更就短了，加上读盘速度更快，所以整个读取请求耗时更低，快速处理大量读取请求造成缓存过多的数据块，本身 vm cache 分片数较少，就造成了激烈的锁竞争。
而其极端的限流策略，更是导致资源分配完全偏向于写请求。
一个老难题 - 资源配额
看到这里，相信大伙都会觉得 VM 的限流太拉胯了，一点都不严谨。
那如果要你来实现这个限流，你该如何实现它？在改进这个限流之前，请先想好几个问题。
限流的阈值该如何设置？
要改进限流，第一个容易想到的就是加大读写并行度，就需要在有写请求的时候增加允许读的限流阈值。那么增加多少合理？还是自适应？但这种自适应可不像普通单向流量控制那么简单，这要控制读和写两个方向，而且真的是仅仅控制 QPS 而已吗？
流控是手段，隔离是本质！
读写 QPS 配额的比重能映射到 IO 吞吐上？如果一个读请求，读取几百兆或上千兆的字节，完全占满磁盘的吞吐怎么办？更何况写请求也需要读取数据，所以从 QPS 或者资源来控制都有各自的问题。
PaceLimiter 设计目的就是保证高优先级任务需要的所有资源(主要是 IO)都优先得到满足，而不是独占，还有空闲的资源，也可以分配给低优先级任务。那么需要对两种任务的资源进行隔离，而隔离的限制是弹性的。
所以，完美的实现应该是：当写请求需要资源时，优先分配；资源利用率没有达到 100%时，余下资源可以分配给读请求。
切除阑尾 - 开发团队的做法
在现有技术下，要做到这种完美方案，几乎是不可能实现的，理论在工程上的实现就是一个取舍的过程。
是直接添加一个 QPS 读写配额，通过这种短平快的方式缓解问题，还是找相对更为合理的方案？就在我纠结时，发现开发团队在 v1.86.2 版本中，已经将限流这块逻辑全部都移除掉了，不再对任务做限制。那写请求很可能会被读请求影响，导致监控数据的写入丢失。
至于开发团队的决策，我们不得而知，如果是你，你会怎么做呢？
版权声明: 本文为 InfoQ 作者【楚】的原创文章。
原文链接:【http://xie.infoq.cn/article/409a5ef57c0dfb3a5db226e23】。
本文遵守【CC BY-NC】协议，转载请保留原文出处及本版权声明。
还未添加个人签名 2018-06-12 加入
还未添加个人简介
评论