Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bs构建相关问题 #203

Open
dyuyang opened this issue Nov 14, 2023 · 4 comments
Open

bs构建相关问题 #203

dyuyang opened this issue Nov 14, 2023 · 4 comments

Comments

@dyuyang
Copy link
Collaborator

dyuyang commented Nov 14, 2023

  1. 合理的内存配置
  2. GB级别数据的benchmark
  3. 构建进度提示
@breeent
Copy link

breeent commented Nov 14, 2023

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

@xuxijie
Copy link
Collaborator

xuxijie commented Nov 15, 2023

@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
Copy link

breeent commented Nov 15, 2023

@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 process_starter.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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants