关于compact速度调整

有关这个,


疑问一: 改这个配置的话, 一定要修改成从本地配置文件读取吗?

疑问二: 这个限制读写速率假如设置为500mb/s真的能提高compact读写速率吗?(默认是30mb/s), 修改后那么自动和手动的compact都是按照这速度吗???

疑问三: 开启自动的compact后, 还有必要手动执行compact吗?

疑问四: 这个手动的submit job compact只是正对当前spacs吗?

疑问五: drop 操作会删除数据, 那么自动compact和手动compact后都会真正的从磁盘删除数据吗? 我试了手动的compact确实是从磁盘删除了

额外疑问, int和double和范围一样吗??? 还有没有比int更大的整型数据类型呢?

疑问一: 改这个配置的话, 一定要修改成从本地配置文件读取吗?

wey: 不是所有的配置都做成了可以从meta去集中配置(local config 的反面:false),这里需要local false,然后通过文件或者启动参数配置。

疑问二: 这个限制读写速率假如设置为500mb/s真的能提高compact读写速率吗?(默认是30mb/s), 修改后那么自动和手动的compact都是按照这速度吗???

wey: 这里是上限,是同时影响自动和手动的 compaction

疑问三: 开启自动的compact后, 还有必要手动执行compact吗?

wey: 自动不是全量的,手动的全量 compaction 是更耗时的操作,但是它会让数据的混乱程度更小。定期手动全量 compaction 的收益是提升读写性能、代价是比自动增量更费时。

疑问四: 这个手动的submit job compact只是正对当前spacs吗?

wey: 是的,这个 job 需要在 Use Space 之后。

疑问五: drop 操作会删除数据, 那么自动compact和手动compact后都会真正的从磁盘删除数据吗? 我试了手动的compact确实是从磁盘删除了

wey: @critical27 可以帮忙回复一下么? drop之后下一次auto compact 一定会删除么?

额外疑问, int和double和范围一样吗??? 还有没有比int更大的整型数据类型呢?

wey: double range 可以参考 IEEE-754
int 现在是最大的整形,还没有更大的哈
如果有需求超过int64,可以考虑存到两个 int 里,自己读写时候去做偏移处理

2 个赞

其实我一直没懂这从meta获取配置的说法, wey老师你看下我理解的对不对哈: /usr/local/nebula/etc这个路径下有meta, graph, storage三个目录中都有各自配置文件, 默认的话, graph和strage都是从nebula-metad.conf这个配置文件获取配置数据; 如果设置了local_config=true了, 那就是graph,storage会去 /usr/local/nebula/etc目录下的graph和storage目录下从各自的配置文件:nebula-graphd.conf nebula-storaged.conf获取配置了? 我理解的对吗???
image

rocksdb_db_options配置中也有个rete_limit配置, 这个和compact的rate_limit不是一回事吧?

关于三种不同进程在不同的配置的部分是正确的,对 true 的 理解也对哈。

这里通过 meta 管理的配置是所有配置的真子集,它的范围是 /usr/local/nebula/share/resources/gflags.json 里的哈。

local_config=flase 意味着 gflags 里的配置将忽略 conf 里的,反之将忽略 meta 之中集中集中管理的。

和 dev 同学确认了下,这两个是一个,都是只限制 compaction 的rate

1 个赞

对了, 忘了问, rete_limit单位都是mb/s吗? 这个很重要

MB per second, B 应该是 Byte

https://github.com/vesoft-inc/nebula-storage/blob/d6b61b8cf520dca8ecd7d478d1c9b8dcc27bc369/src/kvstore/RocksEngineConfig.cpp#L75

2 个赞

是Byte,通常描述数据在网络(协议)上传输时使用bit,当数据通过数据(协议)传输时使用Byte

1 个赞

不管是啥, 我都没办法提高速度了, 默认是0不限制, … :joy:

疑问一: 改这个配置的话, 一定要修改成从本地配置文件读取吗?

这个配置的意义在于启用配置文件

疑问二: 这个限制读写速率假如设置为500mb/s真的能提高compact读写速率吗?(默认是30mb/s), 修改后那么自动和手动的compact都是按照这速度吗???

compact速率与系统性能有关,这个设置是为了避免compact影响nebula graph的整体性能而做的一个配置项,本身不是一个优化性能的选项。如果你对compact速度有一定要求,需要先释放这里的限制。

疑问三: 开启自动的compact后, 还有必要手动执行compact吗?

开启自动compact后,通常没必要手动跑compact,等自动回收就行

疑问四: 这个手动的submit job compact只是正对当前spacs吗?

是的,因为你在执行这个命令的时候,已经在某个space下了。 自然无法管理其他的space

疑问五: drop 操作会删除数据, 那么自动compact和手动compact后都会真正的从磁盘删除数据吗? 我试了手动的compact确实是从磁盘删除了

compact后会真正的删除数据,你的测试结果是正确的。自动和手动的结果没区别,只是如何触发compact的区别而已。

额外疑问, int和double和范围一样吗??? 还有没有比int更大的整型数据类型呢?

不一样,详情见文档 https://docs.nebula-graph.com.cn/2.0.1/3.ngql-guide/3.data-types/1.numeric/#int

感谢再次回复, 其他我没问题, 就是这个我因为之前关了自动compact导入200亿数据,途中报错了, 报错信息是 Too many open files…就是打开句柄太多了, 我看了一下最大的是storage, 990W+ 最终导致我啥也干不了了, 一直报错(手动compact也这个错误); 第二次重新新开始个集群开着自动compact才能一直导入成功, 根据我现有的经验, 我理解自动的compact是回收的慢, 手动的能快速回收大量资源句柄, 举个例子, 我80亿数据导入刚刚完成, 句柄已经300W了, 然后我立马执行全量compact, 句柄能马上回收到30W+

最终目的, 其实我们机器还是很强的, 就想让在做compact和stats的时候让快点, 下面是我自己百度配置的一些rocksdb参数, 希望能导入数据速度快点, 望指正

该主题在最后一个回复创建后7天后自动关闭。不再允许新的回复。

浙ICP备20010487号