search

alibaba / havenask

Apache License 2.0
1.6k stars 302 forks source link

bs构建相关问题 #203

Open dyuyang opened 1 year ago

dyuyang commented 1 year ago
  1. 合理的内存配置
  2. GB级别数据的benchmark
  3. 构建进度提示
breeent commented 1 year ago

数据量较大的时候索引构建确实比较慢，改哪些配置可以加快构建速度呢？

xuxijie commented 1 year ago

@breeent 你可以通过下面方法提升索引构建速度：

  1. 如果是单机版的，可以修改成分布式版本，分片越多build速度越快，但是需要的资源越多。在分布式版本下，如果是数据处理较慢，你可以修改data_tables下面的配置，将processor的partition个数调大
  2. 对于单个节点来说，你可以通过修改容器的资源，比如cpu和内存来提升速度，这个在bs_hippo.json下面，目前只有cpu的限制，内存默认为5G，你可以将其修改为下面的格式 { "amount": 300, "name": "cpu", "type": "SCALAR" }, { "amount": 10240, "name": "mem", "type": "SCALAR" }，具体的资源数需要根据数据来确定
  3. 目前的cluster.json中缺少了build_total_memory的配置，你可以在这个配置文件中online_index_config统计别添加下 "offline_index_config" : { "build_config" : { "build_total_memory" : 10240, "keep_version_count" : 10 }，这个内存大小要比容器的内存小一些。
  4. 目前索引构建时segment的产出收到sort_queue内存大小和队列中文档个数的限制，如果内存较小或者文档个数较小就会频繁dump，这样也会影响build速度，你可以根据情况调整一下，如果内存充足的话，内存可以配置为10240（10G），队列大小可以配置为10000000
breeent commented 1 year ago

@xuxijie 我测试的机器是96核376G的，把bs_hippo.json里面的配置改到了 { "amount": 3000, "name": "cpu", "type": "SCALAR" }, { "amount": 51200, "name": "mem", "type": "SCALAR" } cluster.json添加了 "offline_index_config" : { "build_config" : { "build_total_memory" : 51000, "keep_version_count" : 40 } } sort_queue相应的配置也改为： "sort_queue_mem": 30720, "sort_queue_size": 100000000

前面cpu和内存使用率确实有所提高，cpu大概用到1500%，但离配置的3000%差别还挺大的。过了大约一个小时以后看只有一个build_service_worker进程在占用cpu，在机器资源充足的情况下cpu也只用了大约400%，启动参数是 1000613 pts/1 Ss+ 0:00 sh processstarter.sh 1000619 pts/1 Sl+ 17:38 \ build_service_worker -l /home/ha3/havenask/data_store/conf_test/perf_test/conf/cluster_templates/havenask/offline_table/bs_alog.conf -d rpc -w /home/ha3/havenask-bs-local_database.in0.1700018544.task.taskId=fullBuilder-name=master-taskName=builderV2.0.65535.in0/build_service_worker -s database -m havenask-bs-local -z zfs://10.106.129.43:2181/havenask/havenask-bs-local -r database.in0.1700018544.task.taskId=fullBuilder-name=master-taskName=builderV2.0.65535.in0 -a 10086 这个进程的内存涨到50G以后就会消失然后重新拉起一个启动参数一样的进程，一直到现在持续了五个小时，hape gs table -t in0也一直是not_ready的状态。 数据量大概500w，文件大小也只有几G，我理解这个量级单机版应该也够了。 有没有什么办法看是不是出了什么问题，还是构建没结束？如果构建没结束的话怎么样能再加快一些，cpu并没有跑满。

希望能早点有 GB级别数据的benchmark 出来，这样能照着改会更好一些

zhenxinxu commented 1 year ago

有没有启动merger 服务？可以看看full-builder 里面的bs.log 有没有什么报错