作者:张富春(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按照一定比例混合发送的时候,性能表现又是怎么样的?