vm-storage在全部都是旧metric情况下的写入性能测试
作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！
接上篇：测试所有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按照一定比例混合发送的时候，性能表现又是怎么样的？
