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

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

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

---

接上篇：测试所有metric都是存在过的metric的情况下，单核的极限写入性能。也就是说，只增加数据部分，不影响索引部分。

1.基础信息

• CPU 1核
• 内存 8GB
• 本地磁盘（应该是SATA盘）
• metric的平均长度：513字节
• vm-storage版本：v1.78.0-cluster
• 压测方法：使用remote write协议写入完全不同的metric数据，每次发送1000条，每核50个并发，一共15核。
  • vm-insert 5 实例，共20核，资源充足
  • vm-insert的关键参数如下：
    • -maxConcurrentInserts=默认值
    • -sortLabels: 开启label的排序。
    • -insert.maxQueueDuration=3s，允许在队列中等待的最长时间。
    • -dropSamplesOnOverload: 为了保护vm-insert自身，在vm-storage变慢后，立即丢弃数据。

2.vm-storage性能表现

• CPU占用：0.80核~0.89核 (相当于CPU资源已经到瓶颈了)
• 内存：3.52GB， 占44%
• 网络入流量：810kb/s
• 磁盘读：平均100kb~200kb/s， 峰值2.38mb/s ，最高延迟 5.14ms
• 磁盘写：平均100kb~500kb/s，峰值7.05mb/s, 最高延迟 43.6ms
  • 相比于写入索引，写入数据所占用的IO要小得多
• 新的metric的占比 0%, slow insert的占比0%（显而易见） , tsid cache的miss率 0%（显而易见）
• 每秒写入的data point数量：43万/s
• vm-insert端：
  • 请求量：431583/s
  • 丢弃量：5028/s

3.总结

• 当所有的time series都是旧的情况下， vm-storage的的单核的极限写入性能大约是：43万/s
• 磁盘读是写入流量的 四分之一， 磁盘写是写入流量的 二分之一
• 当写入量过大时，CPU是瓶颈。内存、网络流量和磁盘IO的资源占用相对较小。
• 根据压测数据：写入索引的成本是写入数据的 43万 / 6000 = 71.7倍

4.遗留问题

• 怎么样让vm-insert尽量不丢包，又不会导致过载？
• vm-insert的资源与vm-storage的配比是怎么样的？配置多少vm-insert才能不出现drop数据？
• 旧metric和新metric按照一定比例混合发送的时候，性能表现又是怎么样的？