gpt4 book ai didi

elasticsearch - 闲置时Elasticsearch High CPU

转载 作者:行者123 更新时间:2023-12-02 22:25:38 26 4
gpt4 key购买 nike

我是Elasticsearch的新手,遇到了一个问题,甚至在故障排除方面也遇到了困难。我的Elasticsearch(1.1.1)当前正在使CPU处于运行状态,即使没有进行搜索或建立索引也是如此。 CPU使用率并不总是100%,但是它跳了很多,并且负载很高。

以前,该节点上的索引可以完美运行几个月,没有任何问题。这只是今天开始的,我不知道是什么原因造成的。

即使我重新启动ES之后,问题仍然存在,甚至我甚至在绝望中重新启动服务器。对这个问题没有影响。

这里有一些统计数据可以帮助解决问题,但我想还有更多需要的信息。我只是不确定要提供什么。

Elasticsearch 1.1.1
Gentoo Linux 3.12.13
Java版本“1.6.0_27”
OpenJDK运行时环境(IcedTea6 1.12.7)(Gentoo版本1.6.0_27-b27)
OpenJDK 64位服务器VM(内部版本20.0-b12,混合模式)

1个节点,5个分片,0个副本

系统上有32GB RAM,16GB专用于Elasticsearch
RAM似乎不是这里的问题。

解决问题的任何技巧将不胜感激。

编辑:如果有帮助,请从顶部开始。

top - 19:56:56 up  3:22,  2 users,  load average: 10.62, 11.15, 9.37
Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie
%Cpu(s): 98.5 us, 0.6 sy, 0.0 ni, 0.7 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 32881532 total, 31714120 used, 1167412 free, 187744 buffers
KiB Swap: 4194300 total, 0 used, 4194300 free, 12615280 cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2531 elastic+ 20 0 0.385t 0.020t 3.388g S 791.9 64.9 706:00.21 java

最佳答案

正如安迪·普赖尔(Andy Pryor)所提到的,后台合并可能是导致此问题的原因。我们的索引过渡已暂停,当前的两个索引超过200GB。将它们滚动显示似乎已解决了该问题,此后我们一直在嗡嗡作响。

编辑:
确定看似闲置时的高负载是由几个非常大的索引合并而成的,这些合并每周都不进行。这是内部流程无法每周滚动索引的失败。解决了这一疏忽之后,合并时间变短了,高负荷消退了。

关于elasticsearch - 闲置时Elasticsearch High CPU,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23394220/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com