场景描述：本文是较早的一篇关于Elasticsearch性能指标监控的博文，内容总结全面，作者 Emily Chang，原文地址：https://www.datadoghq.com/blog/monitor-elasticsearch-performance-metrics，由杨文波同学翻译。
声明：本文是较早的一篇关于Elasticsearch性能指标监控的博文，内容总结全面，作者 Emily Chang，原文地址：https://www.datadoghq.com/blog/monitor-elasticsearch-performance-metrics，由杨文波同学翻译。
Elasticsearch是一个开源的分布式文档存储和搜索引擎，可以近乎实时地存储和检索数据结构，它很大程度上依赖于Apache Lucence--一个用Java编写的全文搜索引擎。
当使用 Elasticsearch 进行更大的时间数据分析用例时，我们建议使用基于时间（time-based）的索引和具有 3 种不同类型节点（主节点、热节点和冷节点）的分层架构，我们称之为Hot-Warm架构。每个节点都有自己的特性，如下所述。
这是系列文章的第四篇，主要探讨：Elasticsearch JVM 堆内存使用率飙升，怎么办？
近期在优化索引时，我遇到了一些挑战。我们的环境是7节点16*32G的机器，我在尝试内存优化。当前的文档总量为5亿，然而mapping设计和shard设计都出现了问题。每个节点上有480个shard，这是一个相当离谱的数量。
在过去的 10 个月里，我很高兴与个性化和相关性团队合作。我们负责根据排名和机器学习向用户提供“个性化和相关的内容”。我们通过一组提供三个公共端点的微服务来做到这一点，即 Home Feed、Search 和 Related items API。我记得加入团队几个月后，下一个挑战是能够为更大的关键国家提供优质服务。目标是保持我们在较小国家/地区已经拥有的完美性能和稳定性。
由于Solr和ElasticSearch都是基于Lucene构建的，所以他们之间有很大程度的相似性，故而他们的一些优化策略基本也是通用的，面对越来越多的海量数据，如何优化全量索引的写入性能呢？ 散仙简单总结了下面几个方向的优化策略，如有疑问，欢迎拍砖。 （一）硬件优化： （1）CPU加大，有利于并发写入 （2）内存提升，加大写入缓冲 （3）磁盘IO，使用SSD或者IO读写更快的磁盘 （4）网络IO，保证客户端与服务端的通信带宽充足 （二）服务端框架优化： （1）加大shard的数目，理论
项目中的服务集成了springboot-admin做服务监控，最近一直收到邮件告警，提示es出错。错误信息如下：
在生产环境搭建或维护 Elasticsearch 集群和个人搭建集群的小打小闹有非常大的不同。
Elasticsearch是一个基于Lucene的搜索和分析引擎，能够处理大规模的数据并提供实时的搜索和分析功能。为了充分发挥Elasticsearch的性能，集群搭建时的Linux系统设置优化至关重要。本文将分模块详细介绍如何优化Linux设置，以确保Elasticsearch集群的高效运行。
Elasticsearch 和 Lucene 都是 Java 语言编写，这意味着我们必须注意堆内存的设置。
1、什么是堆内存？ Java 中的堆是 JVM 所管理的最大的一块内存空间，主要用于存放各种类的实例对象。 在 Java 中，堆被划分成两个不同的区域： 新生代 ( Young )、 老年代 ( Old )。 新生代 ( Young ) 又被划分为三个区域 Eden、 From Survivor、 To Survivor。 这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象，包括内存的分配以及回收。 2、堆内存的作用是什么？ 在虚拟机启动时创建。 堆内存的唯一目的就是创建对象实例，所有的对象实例
1. 如果你的堆大小不是很大（比如 100MB），选择串行收集器一般是效率最高的。
Elasticsearch具有通用性，可扩展性和实用性的特点，集群的基础架构必须满足如上特性。合理的集群架构能支撑其数据存储及并发响应需求。相反，不合理的集群基础架构和错误配置可能导致集群性能下降、集群无法响应甚至集群崩溃。
大多数操作系统都尽可能多地为文件系统缓存使用内存，并切换出未使用的应用程序内存。这可能导致部分JVM堆被交换到磁盘上。
G1（Garbage-First）垃圾收集器是一种服务器端的垃圾收集器，用于替换老旧的CMS（Concurrent Mark-Sweep）收集器。G1收集器旨在以高概率满足垃圾收集（GC）暂停时间目标，同时还能保持良好的吞吐量。G1收集器通过将堆分割成多个大小相等的独立区域（Region）来实现其目标。这些区域可以分为几种类型，每种类型的区域都有其特定的用途。
若观察到Tomcat进程CPU使用率较高，并在GC日志中发现GC次数比较频繁、GC停顿时间长，说明需优化GC。
先来看下Oracle HotSpot JVM的体系结构： JVM主要组件包括，类加载器，运行时内存区，以及执行引擎，程序员主要关注的应该是运行时区域这块了， 回顾下类加载器的顺序： ->Bo
本文转载自：https://javadoop.com/post/jvm-memory-management
Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、Spring Boot、Spring Cloud、RabbitMQ、Kafka、Linux等技术栈……
采用zip或tar.gz的二进制包方式安装的ES，需要配置一系列参数，通过阅读官方文档了解到其中重要参数的配置及其说，下面将逐步进行了解。
JVM调优听起来很高大上，但是要认识到，JVM调优应该是Java性能优化的最后一颗子弹。
以下是我们的Core Elasticsearch：Operations课程中的一些很棒的幻灯片，它们有助于解释分片分配的概念。 我们建议您更全面地了解这一点，但我会在此提供我们培训的概述：
在Java中，垃圾收集机制（Garbage Collection）是一种自动的管理内存的机制，用于回收不再使用的对象所占的内存空间。
在默认情况下，通过system.gc()者Runtime.getRuntime().gc() 的调用，会显式触发FullGC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。然而system.gc() )调用附带一个免责声明，无法保证对垃圾收集器的调用。(不能确保立即生效)
垃圾收集是JVM在不再需要内存时代表应用程序回收内存的机制。从高层来看，它包括查找不再使用的对象，释放与这些对象相关联的内存，偶尔压缩堆以防止内存碎片化。
各种清除算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集算法应运而生。
无论是ART还是Dalvik虚拟机，都和众多Java虚拟机一样，属于一种托管内存环境（程序员不需要显示的管理内存的分配与回收，交由系统自动管理）。托管内存环境会跟踪每个内存分配， 一旦确定程序不再使用一块内存，它就会将其释放回堆中，而无需程序员的任何干预。回收托管内存环境中未使用内存的机制称为垃圾回收。
Elasticsearch是非常灵活且功能丰富的搜索引擎，它提供了许多不同查询数据的方法。在实战业务场景中，经常会出现远远低于预期查询速度的慢查询。作为分布式系统的Elasticsearch，可能有各种影响查询性能的因素，包括外部因素，如负载均衡设置，网络延迟（带宽，NIC卡/驱动程序）等。
JVM 11的优化指南：如何进行JVM调优，以及JVM调优参数有哪些”这篇文章将包含JVM 11调优的核心概念、重要性、调优参数，并提供12个实用的代码示例，每个示例都会结合JVM调优参数和Java代码
jstat全称Java Virtual Machine Statistics Monitoring Tool，是随jdk发布的一款用于输出jvm统计参数的命令行工具，用过jvisualvm的肯定会说有了jvisualvm为什么还需要用jstat命令行呢，jstat虽然可视化效果差些，但其在实际生产环境用起来却很方便，一般线上环境不会打开jmxremote功能，这样jvisualvm就无用武之地。
除了释放不再被引用的对象外，垃圾收集器还要处理堆碎块。新的对象分配了空间，不再被引用的对象被释放，所以堆内存的空闲位置介于活动的对象之间。请求分配新对象时可能不得不增大堆空间的大小，虽然可以使用的总空闲空间是足够的。这是因为，堆中没有连续的空闲空间放得下新的对象。
G1（Garbage First）垃圾收集器，是目前垃圾回收技术最前沿的成果之一。
“堆”是一个“运行时”数据区，是通过new等指令建立的，Java的堆是有Java的垃圾回收机制来负责处理的。堆是动态分配内存大小，垃圾收集器可以自动回收不再使用的内存空间。所谓的内存垃圾，是指在堆上开辟的内存空间，在不用的时候就变成了“垃圾”。 Java中，这部分“垃圾”可以被Java虚拟机的一个程序发现并自动清除掉。Java语言提供了一个系统级的线程级——垃圾收集器线程，来跟踪每一块分配出去的内存空间，当JVM处于空闲循环时，自动回收每一块可以回收的内存。 垃圾收集器完全是自动被执行的，它不能被强制执行。程序员可以做的只是调用System.gc()来“建议”执行垃圾收集器程序。将对象的引用变量初始化为null值，来暗示垃圾收集器来收集该对象。 finalize()在该对象垃圾回收前调用。 JVM使用的是分代垃圾回收的方式，主要是因为在程序运行的时候会有如下特点: 1.大多数对象在创建后很快就没有对象使用它了。(98%的对象) 2.大多数在一直被使用的对象很少再去引用新创建的对象。 因此就将Java对象分为年轻对象和年老对象。JVM将内存分为两个区域，分别称为“新生代”和“老年代”。“新生代”区域中绝大多数新创建对象都存放在这个区域里，一般来说较小而且垃圾回收频率较高。“老年代”区域中存放的是在“新生代”中生存了较长时间的对象，这些对象将被转移到“老年代”区。
G1收集器（Garbage-First Garbage Collector，简称G1 GC）是Java虚拟机（JVM）中的一种垃圾收集器，专为服务器端应用设计，特别适用于具有多核处理器和大内存的机器。G1 GC在JDK 7u4版本中被正式推出，并且在JDK 9中成为默认的垃圾收集器。它的主要目标是在满足高吞吐量的同时，尽可能缩短垃圾收集造成的停顿时间。
Java虚拟机（JVM）是Java程序的核心执行引擎，它的性能对于保证Java应用的稳定性和高效性至关重要。JVM调优是优化Java应用性能的关键一环，本文将从JVM原理、内存管理、垃圾回收机制、调优工具等多个方面进行详细阐述，帮助读者全面理解和掌握JVM调优的技术。
上文已经讲解垃圾收集的各种算法，算法可以理解为方法，如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。
在默认情况下，通过system.gc()或者Runtime.getRuntime().gc() 的调用，会显式触发Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。
Java 应用程序的性能优化是一个常见的技术难题。要提高 Java 应用程序的性能，需要综合考虑以下几个方面：
垃圾收集，不是Java语言的伴生产物。早在1960年，第一门开始使用内存动态分配和垃圾收集技术的Lisp语言诞生。
近一年内对公司的 ELK 日志系统做过性能优化，也对 SkyWalking 使用的 ES 存储进行过性能优化，在此做一些总结。本篇主要是讲 ES 在 ELK 架构中作为日志存储时的性能优化方案。
72 System.gc() 和 Runtime.gc() 的作用？有什么区别？
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html
在枚举根节点时，所有的用户线程都会被被暂停，因为在根节点枚举过程中，为了保证分析结果的准确性，需要保证根节点的引用关系不会发生变化。即根节点的枚举必须在一个能保障内存一致性的快照中。
前提： 某大型跨境电商业务发展非常快，线上机器扩容也很频繁，但是对于线上机器的运行情况，特别是jvm内存的情况，一直没有一个统一的标准来给到各个应用服务的owner。经过618大促之后，和运维的同学讨论了下，希望将线上服务器的jvm参数标准化，可以以一个统一的方式给到各个应用，提升线上服务器的稳定性，同时减少大家都去调整jvm参数的时间。 参考了之前在淘宝天猫工作的公司的经历：经过大家讨论，根据jdk的版本以及线上机器配置，确定了一个推荐的默认jvm模版： 最终推荐的jvm模版： jdk版本 机器配置 建议jvm参数 备注 jdk1.7 6V8G -server -Xms4g -Xmx4g -Xmn2g -Xss768k -XX:PermSize=512m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=68 -verbose:gc -XX:+PrintGCDetails -Xloggc:{CATALINA_BASE}/logs/gc.log -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath={CATALINA_BASE}/logs 前台 jdk1.7 8V8G -server -Xms4g -Xmx4g -Xmn2g -Xss768k -XX:PermSize=512m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=68 -verbose:gc -XX:+PrintGCDetails -Xloggc:{CATALINA_BASE}/logs/gc.log -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath={CATALINA_BASE}/logs 前台 jdk1.7 4V8G -server -Xms4g -Xmx4g -Xmn2g -Xss768k -XX:PermSize=512m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=68 -verbose:gc -XX:+PrintGCDetails -Xloggc:{CATALINA_BASE}/logs/gc.log -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath={CATALINA_BASE}/logs 前台 jdk1.7 6V8G -server -Xms4g -Xmx4g -XX:MaxPermSize=512m \ -verbose:gc -XX:+PrintGCDetails -Xloggc{CATALINA_BASE}/logs/gc.log -XX:+PrintGCTimeStamps \ 后台 某互联网（bat）公司的推荐配置：
我们知道之所以java比较容易上手,很大的原因是由于我们不需要关注对象的回收和释放，可以减少不少的工作量，但是完全交由虚拟机回收，也会带来回收性的不确定性。
前提： 某大型跨境电商业务发展非常快，线上机器扩容也很频繁，但是对于线上机器的运行情况，特别是jvm内存的情况，一直没有一个统一的标准来给到各个应用服务的owner。经过618大促之后，和运维的同学讨论了下，希望将线上服务器的jvm参数标准化，可以以一个统一的方式给到各个应用，提升线上服务器的稳定性，同时减少大家都去调整jvm参数的时间。 参考了之前在淘宝天猫工作的公司的经历：经过大家讨论，根据jdk的版本以及线上机器配置，确定了一个推荐的默认jvm模版： 最终推荐的jvm模版： jdk版本 机器配置 建议jvm参数 备注 jdk1.7 6V8G -server -Xms4g -Xmx4g -Xmn2g -Xss768k -XX:PermSize=512m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=68 -verbose:gc -XX:+PrintGCDetails -Xloggc:{CATALINA_BASE}/logs/gc.log -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath={CATALINA_BASE}/logs 前台 jdk1.7 8V8G -server -Xms4g -Xmx4g -Xmn2g -Xss768k -XX:PermSize=512m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=68 -verbose:gc -XX:+PrintGCDetails -Xloggc:{CATALINA_BASE}/logs/gc.log -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath={CATALINA_BASE}/logs 前台 jdk1.7 4V8G -server -Xms4g -Xmx4g -Xmn2g -Xss768k -XX:PermSize=512m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=68 -verbose:gc -XX:+PrintGCDetails -Xloggc:{CATALINA_BASE}/logs/gc.log -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath={CATALINA_BASE}/logs 前台 jdk1.7 6V8G -server -Xms4g -Xmx4g -XX:MaxPermSize=512m \ -verbose:gc -XX:+PrintGCDetails -Xloggc{CATALINA_BASE}/logs/gc.log -XX:+PrintGCTimeStamps \ 后台 某互联网（bat）公司的推荐配置： 配置说明： 1. 堆设置 o -Xms:初始堆大小 o -Xmx:最大堆大小 o -XX:NewSize=n:设置年轻代大小 o -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4 o -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5 o -XX:MaxPermSize=n:设置持久代大小 2. 收集器设置 o -XX:+UseSerialGC:设置串行收集器 o -XX:+UseParallelGC:
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
