你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
输入关键字进行搜索
搜索:
没有找到相关结果
code4j - coder github: https://github.com/rpgmakervx
赞同来自: UnigroupAi 、jianjianhe
cyberdak
赞同来自: UnigroupAi
bsll - ES认证考过咯,开心
赞同来自:
elk123
yayg2008
zqc0512 - andy zhou
liulinisgood
要回复问题请先登录或注册
高级Elasticsearch工程师
8 个回复
code4j - coder github: https://github.com/rpgmakervx
赞同来自: UnigroupAi 、jianjianhe
2. 排除1的干扰后,最直观的,看下load高的机器是不是有很多主分片,因为写请求都是集中在主分片执行的,很多人觉得写操作是io密集型的和cpu应该没多大关系,其实不然,es的写操作中贯穿了很多cpu密集型操作,比如分词,id校验,倒排索引数据结构创建,而且还要看下load高的请求队列有没有阻塞,线程数是否合理,bulk index等执行线程数最好不要超过核数的2倍,队列大些不要紧。
3. 如果是2中的情况,建议优化下索引设置,merge flush等参数,还有索引结构,例如如果是日志类的索引,id自动生成,不必要的子弹不索引,去掉doc_value特性,取消_all字段等。这样优化下应该会好很多。
4.如果索引级别优化完了还不行,看下你的主节点和数据节点是否是分离开的,没分开的就分开,如果分开了还这样那就加机器吧,加多少大概估算下,比如3个8核机器平均load12,想下降到正常指标,至少3台吧(假设任务能平均分配到6台机器),这个需要自己根据业务场景评估了。
cyberdak
赞同来自: UnigroupAi
看看
bsll - ES认证考过咯,开心
赞同来自:
elk123
赞同来自:
yayg2008
赞同来自:
code4j - coder github: https://github.com/rpgmakervx
赞同来自:
zqc0512 - andy zhou
赞同来自:
这个load过高是进程数多了,看看写入数据的线程是不是很多,可以分小点。
每个索引可以隔天做forcemerge 减小进程数量。
调整索引shards数,ssd一个 20G左右,HHD一个10G左右。
liulinisgood
赞同来自:
能观察到segment count有下降, 如果在做merge 也不至于 load 这么高吧,都是ssd盘,io完全没问题