问题：

Kibana刷新时Elasticsearch CPU峰值

缑泓

2023-03-14

我在Elasticsearch上遇到了一个问题，我看到它在我的服务器上的CPU使用率达到了176%，所以我想知道这是这个版本中的一个bug还是堆栈本身的一个bug。这种情况并不是偶尔发生的，但在两个小时后，我会看到CPU使用的峰值，有时会导致服务器由于负载而没有响应。

有人也面对这个问题吗？

我的Java版本是

$~# java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

我已经更新了Elasticsearch中的配置，使其消耗的CPU和内存更少。现在我的ElasticSearch.yml配置如下所示

indices.fieldata.cache.size: "30%"
indices.breaker.fielddata.limit: "80%"
indices.breaker.request.limit: "50%"
indices.breaker.total.limit: "90%"
bootstrap.mlockall: true
index.merge.scheduler.max_thread_count: 1
indices.store.throttle.type: none

但是，我仍然看到了Elasticsearch的CPU使用率峰值，我已经识别出了它们的出现，当kibana刷新仪表板时，我可以看到超过100%的峰值(107、165...)奇怪的是，内存使用、net I/O和块I/O似乎保持稳定，而CPU却是尖峰

有什么原因的建议或想法吗？

事先谢谢你,

问候！

和一个我用top记录的日志来搜索CPU峰值

root@g:~#cat cpu-log.txt grep colord

6.9 389 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+disableexplicitgc

6.8 389 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+disableexplicitgc

6.7 389 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+disableexplicitgc

6.6 389 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+disableexplicitgc

6.5 389 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+disableexplicitgc

7.3 389 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+disableexplicitgc

83.5 5864 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+disableexplicitgc

57.5 5864 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+disableexplicitgc

110 694 9 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror-xx:+disableexplicitgc

86.6 8100 colord/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/Java-xms256m-xmx1g-djava.awt.headless=true-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:+useparnewgc-xx:cmsinitiatingoccupancyfraction=75-xx:+usecmsinitiatingoccupancyonly-xx:+heapdumponoutofmemoryerror

共有1个答案

章翔宇

2023-03-14

调试CPU使用并不是一项简单的任务，需要更多的信息来找出导致这些尖峰的原因，例如集群的大小、数据量、碎片和副本的数量、索引映射以及您正在可视化的仪表板的属性。

通常，在Elasticsearch上进行查询和聚合时，您应该看到CPU使用的增加，增加的幅度取决于我上面列出的信息。

作为一个起点，我建议您遵循Elasticsearch的生产指南，因为我看到您是在一些默认设置下运行的，而且您可能希望从使用chrome网络工具开始，重新加载仪表板以查看发送到Elasticsearch的网络请求，运行对/_msearch请求的所有响应，并检查每个查询的taked值，这将使您对ES可能正在处理的较大查询有一个感觉。

类似资料：

何时刷新BufferedWriter

问题内容：在Java程序（Java 1.5）中，我有一个BufferedWriter，它包装了Filewriter，并且多次调用write（）…结果文件很大… 在此文件的各行中，其中一些是不完整的… 我每次写东西时都需要调用flush（但是我怀疑这样做效率不高）还是使用BufferedWriter的另一种方法还是使用另一种类…？（由于我要编写的行数不胜数，所以我确实希望有一些高效的东西。）理想
刷新与刷新

问题内容：如果将新文档索引到Elasticsearch索引，则可在索引操作后1秒钟左右搜索新文档。但是，可以通过调用或对索引进行操作来强制使该文档可立即搜索。这两个操作之间有什么区别- 结果似乎对他们来说是相同的，可以立即搜索文档。这些操作中的每一项到底是什么？ ES文档似乎并未深入解决此问题。问题答案：您得到的答案是正确的，但我认为值得详细说明。刷新有效地调用了Lucene索引读取器上
刷新

2.12　刷新 2.12.1 描述此接口用于增加内容刷新任务 2.12.2　请求地址地址: https://api.bokecs.com/cont/add_refresh 2.12.3　请求方式 POST 2.12.4　请求参数 1) 请求入参 Urls 待刷新的链接 2）请求出参 { "code": "", "message": "" } code：接口响应代码。200表示成功。 mess
Kafka elasticsearch连接器-“刷新超时过期，记录未刷新：”

我有一个奇怪的问题与Kafka->elasticsearch连接器。当我第一次启动时，我在elasticsearch中收到了一个新数据，并通过kibana dashboard进行了检查，但当我使用同一个producer应用程序在kafka中生成新数据并尝试再启动一次connector时，我在elasticsearch中没有得到任何新数据。现在我遇到了这样的错误：我正在使用next命令运行连接器：
刷新页面而不刷新iframe

问题内容：我有一个文件，其中我在页面顶部显示外部页面（使用iframe），其他部分是写在文件中的html代码的输出。 HTML代码如下所示：现在，我想以编程方式刷新页面而不刷新。我的问题是我可以不刷新页面就刷新页面吗？答案/提示将不胜感激。问题答案：该嵌在主HMTL页面（或在JSP）。因此，如果刷新页面，则肯定会再次加载iframe。为了避免这种情况，我可以考虑以下两种选择：使用A
使用typescript时nodemon未刷新

我正在开发一个带有NodeJs、Express、types cript和no清新的应用程序。但是当我更改ts文件中的一些代码时，页面没有刷新。如何在js中编译ts文件并使用no清新浏览器（或其他工具）？包裹json 所以，每次我进行更改，我都需要停止服务器并重新运行npm start

Kibana刷新时Elasticsearch CPU峰值

共有1个答案

相关问答

相关文章

相关阅读

相关工具

相关文档