郑州企业网站排名,罗源做网站的公司,聚名网是干什么的有风险的,做论坛网站好吗ViveNAS是一个开源的NAS文件服务软件#xff0c;有一套独立自创的架构#xff0c;ViveNAS希望能做到下面的目标#xff1a; - 能支持混合使用高性能的介质(NVMe SSD)和低性能介质#xff08;HDD#xff0c;甚至磁带#xff09;。做到性能、成本动态均衡。因此ViveNAS使用…ViveNAS是一个开源的NAS文件服务软件有一套独立自创的架构ViveNAS希望能做到下面的目标 - 能支持混合使用高性能的介质(NVMe SSD)和低性能介质HDD甚至磁带。做到性能、成本动态均衡。因此ViveNAS使用了LSM tree结构使用其带来的分层能力。 - 能提供文件接口对象接口统一访问。ViveNAS的中间层 libvivenas 提供了用户态文件语义方便对象存储对接开发。 - 要方便使用EC进一步降低数据存储的成本底层数要避免随机写。此目标通过PureFlash的Append only file达到。 - 分布式存储的其他横向扩展、高可用能力通过底层的PureFlash系统达到。 其结构介绍祥见ViveNAS - 一个基于LSM tree的文件存储实现 一_pureflash 元数据-CSDN博客
简单讲ViveNAS包括了PureFlash后端存储rocksdb引擎vivenas文件系统以及ganesha前端接口四个部分。 本文记录的是调整rocksdb 的num_levels参数对最终性能的影响。
测试硬件为 阿里云虚机 ecs.hfr7.3xlarge 12C96G。
为避免后端存储对性能的影响使用ramdisk代替SSD作为PureFlash的物理盘。
测试操作
本次进行了三次测试分别设置data column family 的num_levels 为7,4,2 进行测试(meta column family 一直保持为缺省的7
测试负载用fio产生用NFS将ViveNAS文件系统挂载到同一个主机上对nfs文件系统进行读写。首先 进行一次4K随机写(RW), 然后换不同IO大小进行随机读RR fio每次运行30s. 测试脚本详见ViveNAS/testing/perf-stat.sh at master · cocalele/ViveNAS (github.com)
得到如下的测试结果 可以看到有这么几个现象
1) num_levels对初始写的性能影响不大。
2) num_levels对实际造成的底层存储写入量影响也不大这个还是比较诧异的。
3num_levels对读操作的影响明显。特别是32K 随机读表现的更为明显。 简单分析一下
ViveNAS处理大IO读(16K) 比 小IO(4K)性能要好的多。这一点可能跟ViveNAS保存数据以64KB为一个extent有关。无论客户端请求的数据块是4K还是16K底层都要读取最少64KB数据。
算一下读放大倍数也证实了这点4K随机读伴随着43倍写放大。32K随机读只有1.7倍64K随机读更是降低到了0.5倍也就是大部分数据都在rocksdb或者PureFlash AOF cache处得到了复用。 这个测试结果还是揭示了很多问题接下来的研究以及改进方向如下
1. 修改ganesha了worker thread的数量看其对结果的影响 2. 修改libvivenas的vn_read/vn_write操作为异步的看其对结果的影响 3. 修改rocksdb Get函数提供随机读能力去掉不必要的读放大。
