vm-storage在全部都是新metric情况下的写入性能测试

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

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

---

vm-storage中，写入索引的性能要比写入data point慢很多。

通常，每条time series的数据，索引的数量是label总数的4~6倍。例如，一条time series有10个label，则至少会创建40个索引。

假设发送给vm-storage的数据全都是全新的metric，vm-storage的极限写入性能到底在什么范围呢？以下是我的测试。

1.基础信息

• CPU 1核
• 内存 8GB
• 本地磁盘（应该是SATA盘）
• metric的平均长度：700字节
• vm-storage版本：v1.78.0-cluster
• 压测方法：使用remote write协议写入完全不同的metric数据，每次发送1000条，每核50个并发，一共5核。
  • vm-insert 2 实例，共8核，资源充足
  • vm-insert的关键参数如下：
    • -maxConcurrentInserts=默认值：默认每个核四个并发。这个配置很合理，建议不要修改。
    • -sortLabels: 开启label的排序。推荐开启。
    • -insert.maxQueueDuration=3s: 当写入数据太多导致繁忙后，请求最多在队列里面等待3秒。超过3秒还没有资源处理，就会向后端返回503错误。这个时间建议略小于remote write客户端的请求超时时间。
    • -dropSamplesOnOverload: 非常重要，为了保护vm-insert自身，在vm-storage变慢后，立即丢弃数据，避免vm-insert自身的内存爆掉而产生雪崩。

2.vm-storage性能表现

• CPU占用：0.87核~0.93核 (相当于CPU资源已经到瓶颈了)
• 内存：6.33GB， 占79%
• 网络入流量：160kb ~ 200kb
• 磁盘读：6.91MB，最高延迟 25ms
• 磁盘写：8.14MB，最高延迟 43ms
• 新的metric的占比 100%, slow insert的占比100%（显而易见） , tsid cache的miss率 100%（显而易见）
• 每秒写入的新metric数量：5998/s
• 新metric与索引数量的倍数关系：29.4 (平均每条metric创建将近30条索引)
• tsid cache占用百分比：98.7%
  • 由此可见：新的metric会写入tsid cache，以便于下次插入相同metric的时候能够提速。如果存在大量昙花一现的metric，必然导致tsid 的 cache miss升高，进而导致slow insert增多。
• vm-insert端：
  • 请求量：11.1万/s
  • 丢弃量：10.8万/s

3.总结

• 当所有的time series都是全新的情况下， vm-storage的的单核的极限写入性能大约是：6000/s
• 当全是新metric时：磁盘读是写入流量的 35.4 倍， 磁盘写是写入流量的 41.7 倍
• 当写入量过大时，CPU是瓶颈，其次是内存。网络流量和磁盘IO的资源占用相对较小。
• 当vm-storage过载时，表现为写入减少，写入延迟升高：
  • 从而，vm-insert的写入协程进入阻塞；
  • 当设置了vm-insert的-dropSamplesOnOverload参数时，vm-insert会把无法发送给vm-storage的数据立即丢弃。
  • 当remote write的请求，在vm-insert上的阻塞时间达到了-insert.maxQueueDuration的时间后，vm-insert会返回http 503错误。
  • 因此：remote write客户端收到503错误后，要减小发送频率；而非503错误要重试一定次数。
  • vm-insert上如果发现vm_rpc_rows_dropped_on_overload_total的数据，则说明vm-storage开始过载，需要扩容；
  • 如果vm-storage的过载是因为短期的新metric太多，应该等一会儿，等到tsid cache的命中率提升后恢复正常写入；