- nebula 版本：3.3.0
- 部署方式：分布式 / 三台机器
- 安装方式：源码编译
- 是否上生产环境：Y
- 硬件信息
- 磁盘 8 T* 12
- CPU 64C、内存 512G
现在写入了50亿节点 600亿条关系 ，昨天执行了submit job stats 一整天了还没有跑完。
随便执行查询语句都是报storage error E_RPC_FAILURE
请问大神们，我这边数据量大概为100亿节点 千亿边，我这些集群配置能不能玩得转？？？
硬盘是HDD
我把写入停了，然后stats 在运行了30个小时左右执行完了，大概600亿边，40亿节点。
但是查询还是报storage error E_RPC_FAILURE
这个报错的话，按照文档的 faq 一般是xi下列原因
show hosts 正常 storage timeout 也改了， 查询语句简单的go 语句 go from “a” over friend yield ᠃᠃᠃
storage 发生过oom 。
rocksdb options 加了个max_open_files = 50000 因为之前内存一直增长。
hdd跑这么大的数据io性能瓶颈很大的，至少换成intel p4500系列ssd吧 
1 个赞
把max_open_files 去掉之后，storaged 起不来了 ，报 check failed while open a file for random read ᠃᠃᠃᠃᠃ too many open files 。
查看了 lsof -p pid 全是打开的sst 文件。 每台机器有十二块盘 然后每个盘下面的sst 文件大概10W ulimit -n 设置的100W 我估计是这个原因报错 12*10 > 100W
storage 重启后 他会扫描所有的数据盘 ，这个过程也非常慢。
我是不是把 max_open_files 设置为小于100W 能起来？
目前木有机器
我看每次storage 重启 都会扫描 sst ，查看losof 都是打开的sst文件，扫描后不释放吗？max_open_files 是控制打开的sst文件个数吗？
是不是把compaction给关了？大批量导入数据过程中就别统计数据量了吧
compaction是关了。。准备单独写个模块统计数据量
那就是compaction的问题，compaction打开，–rocksdb_db_options={“max_subcompactions”:“32”,“max_background_jobs”:“32”} 这个参数设置下
你现在也可以手工提交下compaction任务，先解决open files的问题
–rocksdb_db_options={“max_subcompactions”:“32”,“max_background_jobs”:“32”} 设置过了。。compaction 之前导入的过程中内存一直增长占用很大，就把他关掉了。。。
你把compaction搞完再统计数据量试试，应该不需要单独写模块去统计
现在是sotorage 起不来。。。。手动提交不了 
导入不占用内存，应该是你统计任务占的内存
启动不了是因为open files的问题把，你先设置大了看下，再不行如果可以重新导数据，干脆重新导入吧
ulimit n 已经设置最大了，但是sst 文件个数 超过这个值，我只能把max_open_files 改小点 不知道有没有效果
意思是compaction 打开不影响 内存？