[线上故障case]vmstorage的tsid cache太小，导致 CPU 100%

作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！

• cnblogs博客
• zhihu
• Github
• 公众号:一本正经的瞎扯
  

---

具体的故障细节请看：vm_slow_row_inserts_total reach to 100% when tsid cache space is not enought

一句话总结：vmstorage 配置的内存要足够大到可以 cache 住近期频繁出现的 metric，否则就可能导致极高的 CPU 消耗。

这里线上的故障流程如下：

• 每个新的metric 都会写入这样一条 cache: metric -> tsid，这块 cache 称为 tsid cache
• 当 tsid cache 满后，新的 metric 条目会覆盖最旧的一条，从而保持 cache 的存储空间不变
• 每次写入 metric 数据到 vmstorage 时：
  • 先查询 tsid cache，找到已经存在过的 tsid
  • 如果 tsid cache 未命中，则写入逻辑走入 slow insert 阶段
  • 接下来查询 sstable，从索引中找到 metric 对应的 tsid
    • 如果 sstable 不在内存中，还会导致磁盘 IO
  • 如果找到了 tsid，则不再写入索引，而直接写入数据部分；且当前 tsid 继续写入 tsid cache
  • 如果找不到 tsid，则这一定是全新的 time series，同时写入索引和数据
• 本次故障发生于 slow insert 和 new timeseries create 之间：
  • 因为 tsid 缓存不够，所以重新从索引中找到 tsid，然后又写入 tsid cache的过程中，淘汰掉了最旧的一条
  • 在一定的时间周期内，所插入的 time series 总是在 tsid cache 中没有
  • 从而导致程序逻辑总是走到 slow insert 和 new timeseries create 之间
  • 频繁的 sstable 的 io read + zstd decompress + 字符串前缀匹配 导致了 CPU 100%

我还需要调研一件事情：
假设 metric 字符串的长度是 a, 在时间窗口 b 内，一共存在 time series 是 c 条。那么，假设要保障 99% 的 tsid cache 命中率，tsid 缓存应该设置为多大？