不是。我的意思是我重新创建一个新的图没有导入过的，我再开始把生成的sst 文件分批导入，但是导入一次，如果就compact 一次，这样我测试有可能compact 个别storage 节点comapct 耗时久，导致全部导入过程也很久，现在我共有5000个sst 80G 大小，如果同时一次导入会出现上面一直会有部分storage 节点卡主耗时久的问题，
现在我按照这上面给的把文件分批，导入一批后在compact ，在导入下一批，这样也会出现compact 很久的问题，导致整个导入时间还是很长。大神帮忙分析一下，这边到底该怎样导入？？
你的想法是 分批导入 每导入一次就compact一下是吧？导入多次 compact多次
这其实并不能解决耗时的问题 因为不知道那些文件之间彼此有overlap
从sst数量那里开始跑偏了 ====
- 你的问题是12个storage节点，80G数据大多数都很快ingest结束，只有少数几个节点ingest 4个多小时，且这几个节点在ingest时机器内存是不足的。 （ingest卡住应该不是compact引起的，因为你的自动compact是关闭的）
- 我们测试的800G数据ingest时正常是要6个小时，你的机器正常情况下肯定不需要这么久的。
So，要定位下为啥你的某几个机器内存这么快被占满。
Ps：减少spark partition数，并不能减少sst文件之间存在overlap的概率，基本上100% 都会有overlap的。 这个overlap 会导致ingest时sst文件绝大多数落在L0，会使ingest速度降低，但800G数据测试下有overlap要6小时，无overlap4个多小时，而你只有80G数据，所以这对你的问题的影响可以先忽略不计。
1 个赞
我测试过，这边设置block_cache=8G,这边每ingest 一次一半数据如30G，缓存就长8G ,现在服务32G 故重复ingest3次缓存就满了。这边测试用的是容器机，缓存没法直接自动清理。但这边也测试过，手动清理掉缓存，ingest 有变快了，但是在多次测试缓存还是一下就满了，这个怎么处理？
是要把block_cache=8G 设置小一点吗？？、
同时这个缓存满了是影响ingest 的关键因数吗？？
还有另外不解的是，12个节点storage 导入数据不是异步独立的吗，这边测试发现9个节点启动ingest 有日志，剩下3个一直没有开始执行ingest 也没日志这个是在排队吗？？？还是有compact 卡主了？？
block cache 占用的内存满了 可以设置小一下
我从 Rocksdb常见问题 - Dever 找到有个参数可以控制内存使用。
cache_index_and_filter_blocks这个参数就是使用BlockCache来管理索引数据和bloomfilter数据。打开此选项后，系统的整个内存就是恒定的，不会出现oom问题。
2 个赞
HTTP 命令发给剩下的三个节点了吗？
http这个不知道，在哪里看日志呀
如果是开始 Ingest Storage 日志会打印出 Ingesting extra file 这样的日志
这个日志会有我知道，但是我要问的是，ingest 不是同时异步12个节点一起启动吗？？？这边测试总有几个节点过了好久才启动有日志，这个为什么？？？，感觉是像排队等待其他节点跑完了才启动，或者是卡主了一样
有个参数 meta_http_thread_num 可以控制并行ingest
meta_http_thread_num 这个是配置到meta.conf 配置文件中吧。文档中好像没有这个参数说明可以加上吗
两个 ingest 之间 运行了 8秒？
Increase compact thread 这是之前有 compact 在运行？
如果只有一个节点ingest 慢 能确定这个节点磁盘没问题么？
disable_auto_compactions: true,自动compact 我关掉了，是没起作用吗？？，怎么又有compact？？ 这都是我新建的图旧的图我都删除清空数据重新ingest导入就这一次
磁盘也是ssd 和其他11个节点一样的应该不是磁盘问题吧，还需要什么日志判断是compact 影响的慢，还是磁盘本生就慢啊？我再多测试几遍看看是不是这个节点每次都慢吧
如果只有一个节点慢 可能是这个机器的磁盘有问题 要不然所有节点应该都慢
不是compact 的原因吗？？
你不是关掉了吗 查了一下 rocksdb 代码 这个日志在column_family 里面 没看出启动 compact