文档章节

Elasticsearch monitor reference

Faye_Cai
 Faye_Cai
发布于 2016/06/17 11:26
字数 582
阅读 16
收藏 0

https://www.elastic.co/guide/en/elasticsearch/guide/2.x/heap-sizing.html

 

 

https://www.elastic.co/guide/en/elasticsearch/guide/2.x/_monitoring_individual_nodes.html#_jvm_section

1.

"jvm": {
            "timestamp": 1408556438203,
            "uptime_in_millis": 14457,
            "mem": {
               "heap_used_in_bytes": 457252160,
               "heap_used_percent": 44,
               "heap_committed_in_bytes": 1038876672,
               "heap_max_in_bytes": 1038876672,
               "non_heap_used_in_bytes": 38680680,
               "non_heap_committed_in_bytes": 38993920,
  • The jvm section first lists some general stats about heap memory usage. You can see how much of the heap is being used, how much is committed (actually allocated to the process), and the max size the heap is allowed to grow to. Ideally, heap_committed_in_bytes should be identical to heap_max_in_bytes. If the committed size is smaller, the JVM will have to resize the heap eventually—and this is a very expensive process. If your numbers are not identical, see Heap: Sizing and Swapping for how to configure it correctly.

    The heap_used_percent metric is a useful number to keep an eye on. Elasticsearch is configured to initiate GCs when the heap reaches 75% full. If your node is consistently >= 75%, your node is experiencing memory pressure. This is a warning sign that slow GCs may be in your near future.

    If the heap usage is consistently >=85%, you are in trouble. Heaps over 90–95% are in risk of horrible performance with long 10–30s GCs at best, and out-of-memory (OOM) exceptions at worst.

2.

"gc": {
   "collectors": {
      "young": {
         "collection_count": 13,
         "collection_time_in_millis": 923
      },
      "old": {
         "collection_count": 0,
         "collection_time_in_millis": 0
      }
   }
}

In contrast, the old generation collection count should remain small, and have a small collection_time_in_millis. These are cumulative counts(怎么个累加法?从cluster启动开始累加吗?), so it is hard to give an exact number when you should start worrying (for example, a node with a one-year uptime will have a large count even if it is healthy). This is one of the reasons that tools such as Marvel are so helpful. GC counts over time are the important consideration.

Time spent GC’ing is also important. For example, a certain amount of garbage is generated while indexing documents. This is normal and causes a GC every now and then. These GCs are almost always fast and have little effect on the node: young generation takes a millisecond or two, and old generation takes a few hundred milliseconds. This is much different from 10-second GCs.

Our best advice is to collect collection counts and duration periodically (or use Marvel) and keep an eye out for frequent GCs. You can also enable slow-GC logging, discussed in Logging.

3.

It is much better to handle queuing in your application by gracefully handling the back pressure from a full queue. When you receive bulk rejections, you should take these steps:

  1. Pause the import thread for 3–5 seconds.
  2. Extract the rejected actions from the bulk response, since it is probable that many of the actions were successful. The bulk response will tell you which succeeded and which were rejected.
  3. Send a new bulk request with just the rejected actions.
  4. Repeat from step 1 if rejections are encountered again.

Using this procedure, your code naturally adapts to the load of your cluster and naturally backs off.

Rejections are not errors: they just mean you should try again later.

There are a dozen threadpools. Most you can safely ignore, but a few are good to keep an eye on:

indexing

Threadpool for normal indexing requests

bulk

Bulk requests, which are distinct from the nonbulk indexing requests

get

Get-by-ID operations

search

All search and query requests

merging

Threadpool dedicated to managing Lucene merges

 

© 著作权归作者所有

上一篇: Elasticsearch 维护
下一篇: java heap dump
Faye_Cai
粉丝 0
博文 28
码字总数 5590
作品 0
海淀
高级程序员
私信 提问
Elasticsearch安装、启动

可以参考官网的教程安装 https://www.elastic.co/guide/en/elasticsearch/reference/current/_installation.html 安装jdk 安装JDK请参考另一篇博客 https://my.oschina.net/u/4008390/blog/......

watermelon11
2018/11/07
152
0
ElasticSearch远程任意代码执行漏洞(CVE-2014-3120)分析

原理 这个漏洞实际上非常简单,ElasticSearch有脚本执行(scripting)的功能,可以很方便地对查询出来的数据再加工处理。 ElasticSearch用的脚本引擎是MVEL,这个引擎没有做任何的防护,或者沙...

横云断岭
2014/05/23
0
0
elasticsearch搜索建议Completion Suggester

目的:实现淘宝、京东搜索建议功能 准备环境:安装elasticsearch, 并安装拼音插件(https://github.com/medcl/elasticsearch-analysis-pinyin)。我安装的环境为当前最新版6.2.4。 参考官网教...

杰仪
2018/05/12
739
0
Spring Data Elasticsearch 和 x-pack 用户名/密码验证连接

使用Spring Data Elasticsearch连接elasticsearch时,正常情况下只需要在application.properites文件中添加如下配置即可连接: 以看到Spring Data Elasticsearch连接elasticsearch很简单。 ...

kipeng300
2018/04/24
5.2K
0
elasticsearch入门到放弃之elasticsearch-in-java

代码地址:https://github.com/zhaoyunxing92/spring-boot-learn-box/tree/master/spring-boot-elasticsearch 在java中使用自带的api操作。你可以先看下elasticsearch入门到放弃之docker搭建......

zhaoyunxing
07/05
0
0

没有更多内容

加载失败,请刷新页面

加载更多

聊聊nacos的LocalConfigInfoProcessor

序 本文主要研究一下nacos的LocalConfigInfoProcessor LocalConfigInfoProcessor nacos-1.1.3/client/src/main/java/com/alibaba/nacos/client/config/impl/LocalConfigInfoProcessor.java p......

go4it
昨天
2
0
前端技术之:webpack热模块替换(HMR)

第一步:安装HMR中间件: npm install --save-dev webpack-hot-middleware 第二步:webpack配置中引入webpack对象 const webpack = require('webpack’); 第三步:增加devServer配置项: ho......

popgis
昨天
2
0
死磕 java线程系列之线程池深入解析——体系结构

(手机横屏看源码更方便) 注:java源码分析部分如无特殊说明均基于 java8 版本。 简介 Java的线程池是块硬骨头,对线程池的源码做深入研究不仅能提高对Java整个并发编程的理解,也能提高自己...

彤哥读源码
昨天
3
0
虚函数表 图解

虚函数表 图解 p504

天王盖地虎626
昨天
2
0
java反射

学习目标  什么是反射  反射运行原理  了解反射机制的相关类  获取 class 对象的 3 种方式  通过反射获取构造方法并使用  通过反射获取成员变量并调用  通过反射获取成员方法并...

流川偑
昨天
3
2

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部