如何减缓vm中慢插入的次数

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

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

---

偶然发现vm-storage的监控里有这样一个指标：vm_slow_row_inserts_total，能够体现慢插入的次数。

由此做了一个慢插入的报表：

• 分子：sum by () (rate(vm_slow_row_inserts_total{tenant=~"$tenant",namespace=~"$namespace",env_name=~"$env_name",pod_name=~"${cluster}.+"}))
• 分母：sum by () (rate(vm_new_timeseries_created_total{tenant=~"$tenant",namespace=~"$namespace",env_name=~"$env_name",pod_name=~"${cluster}.+"}))
  
  

vm_slow_row_inserts_total是怎么产生的呢？我梳理了一下流程。

主要是这一行：

// VictoriaMetrics-1.72.0-cluster/lib/storage/storage.go:1800
func (s *Storage) add(){
    if s.getTSIDFromCache(&r.TSID, mr.MetricNameRaw) {  // 如果是已经存在的TSID
         // fast path
    }
    // slow path
   // 在这个分支下插入的ts都会记录到 vm_slow_row_inserts_total
}

再看s.getTSIDFromCache()函数，其实就是从 s.tsidCache 这个缓存对象中查询。

tsidCache的key是整个序列化后的 metric， value是tsid。

• 全新的metric必然不在这个cache，因此单位时间的vm_slow_row_inserts_total必然大于等于每分钟新增的time series(也就是vm_new_timeseries_created_total这个指标体现的内容)
• 如果旧的metric不在cache里，就只能通过LSM Tree去查询，必然是慢的。

问题来了，为什么旧的metric不在tsidCache里?

看看tsidCache的初始化，老的版本是可用内存的35%，新的版本中可以通过参数配置。

storage.cacheSizeStorageTSID参数可以配置这个cache的大小。

如果time series的总数太多，占满了这个cache，必然导致cache miss.

最后的结论是：

1.如果流失率不高，可以调高这个cache的大小，这样就能减少vm_slow_row_inserts_total的数量

2.如果流失率高，调高这个cache意义不大。我觉得可以把-retentionPeriod的时间改短，短到这个周期内的大多数time sereis都能被cache住。