作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！
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的命中率提升后恢复正常写入；