Question

我是Elasticsearch的新手，我遇到了一个问题，即使我在排除故障方面遇到了困难。即使没有进行搜索或索引，我的Elasticsearch（1.1.1）目前仍在使用cpu。 CPU使用率并不总是100％，但它会在那里跳得很多，而且负载非常高。

此前，此节点上的索引在几个月内运行良好，没有任何问题。这只是从今天开始，我不知道造成它的原因。

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

以下是一些有助于确定问题的统计数据，但我想象有更多需要的信息。我只是不确定要提供什么。

Elasticsearch 1.1.1
Gentoo Linux 3.12.13
java版本＆＃34; 1.6.0_27＆＃34;
OpenJDK运行时环境（IcedTea6 1.12.7）（Gentoo build 1.6.0_27-b27）
OpenJDK 64位服务器VM（版本20.0-b12，混合模式）

一个节点，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

Answer 1

正如Andy Pryor所说，背景融合可能是造成这个问题的原因。我们的指数展期暂停，我们目前的两个指数超过200GB。滚动他们似乎已经解决了这个问题，我们一直在哼唱，因为。

编辑：看似闲置时的高负荷被确定为由几个非常大的指数合并引起的，这些指数并非每周都被推翻。这是内部流程未能每周滚动指数。在解决这种疏忽后，合并时间很短，高负荷消退。

空闲时弹性搜索高CPU

1 个答案: