最近我们搭建了一个新的Elasticsearch（以下简称ES）集群，集群中有3个master节点和6个data节点，集群使用到的ES版本为7.5.2。其中master节点JVM的堆内存设置为2GB，data节点JVM的堆内存设置为30GB，master和data节点都只用作单一的节点角色（即节点不会同时是master和data两种角色）。因为master不存储数据，所以我们给master三台负载的配置都比较低。master配置不够导致读写出错我们在操作ES集群的时候使用了elasticsearch-py这个ES的Python操作库，问题在于这个库在操作ES的时候会先根据ES的/_nodes/_all/http接口获取集群所有节点的HTTP接口地址，之后利用这些接口地址对ES进行读写。当然elasticsearch-py会在这些接口地址间做负载均衡以及错误重试等等操作，但是/_nodes/_all/http接口会同时返回master、data以及一些其它角色节点的HTTP接口地址，这就导致elasticsearch-py在后面操作集群的过程中既会读写data节点，也会读写master节点。因为我们master节点的配置很低，所以一旦在master节点上面进行读写操作，那么master节点的压力尤其是内存的压力就会比较大，经常就会出现circuit_breaking_exceptio ...继续阅读 (75)

与C、C++等手动管理内存的编程语言不同，Java程序在运行时会自动对内存中不再使用的对象进行检测，并回收这部分对象所占用的内存空间。在JDK中，JVM将堆（heap）内存分为了不同的区域块，每种区域会使用不同的垃圾收集器，每种垃圾收集器又会使用各自的垃圾收集算法。因此JVM的垃圾收集设计大致架构如下，从上至下越来越偏向于细节，本文使用自底向上的方式进行介绍堆内存堆内存分为多个区域每个区域使用了不同的垃圾收集器每种垃圾收集器使用了一个或多个垃圾收集算法垃圾收集算法检测垃圾的方式一般有引用计数法和可达性分析两种，因为引用计数法无法检测到循环引用的垃圾对象，所以现在JVM中进行垃圾检测都是使用的可达性分析方法。在检测到了垃圾对象之后，JVM就需要对这些垃圾对象进行垃圾回收（英语：Garbage Collection，缩写为GC），JVM中使用到的GC算法主要由如下三种标记-清除算法（Mark-Sweep）该算法分为标记和清除两个步骤，第一步标记是将所有活动的对象做上标记，第二部清除是将所有没有标记的对象进行回收。标记-压缩算法（Mark-Compact）标记压缩算法和标记清除算法基本上一致，只是标记清除算法过程只能单纯的把对象内存空间给释放出来，时间长了会造成内存碎片的问题。标记压缩算法在标记清除算法的基础上会对存活的对象进行移动，之后把这些对象向某一端进行移动来保证有完整的内存空闲空 ...继续阅读 (69)

最近对Elasticsearch（以下简称ES）进行了升级，升级之后把部分数据从之前的ES-1.5集群同步到了现在的ES-7.5集群，之后在新集群中进行数据查询的时候发现会有偶发性的查询非常慢的情况。新集群的大部分查询耗时都在10ms以内，但是偶尔却会出现800ms左右的超高查询耗时，本文记录了该问题的排查过程。GC的原因？首先我们怀疑是ES的GC导致了偶发性的慢查询，我们知道JVM的GC会导致Stop The World现象，在GC时节点无法处理任何逻辑导致查询行为被阻塞最终导致超长的查询耗时，而GC这种行为本身也是会偶发的，所以和我们观察到的偶尔出现查询耗时非常高的现象非常吻合。我们观察ES运行的GC日志，并未看到有延迟特别高的GC行为，而且也没有看到任何Old GC的动作，因此这些慢查询应该并不是因为JVM的GC行为导致的。顺便介绍一下，我们使用的是ES-7.5.2自带的bundled JDK，它的版本为13.0.1~ java -versionopenjdk version "13.0.1" 2019-10-15OpenJDK Runtime Environment AdoptOpenJDK (build 13.0.1+9)OpenJDK 64-Bit Server VM AdoptOpenJDK (build 13.0.1+9, mixed mode, sharing)在 ...继续阅读 (67)

公司目前所使用的Elasticsearch（以下简称ES）版本是在2015年的时候选择的，当时选择了ES的最新版本1.5.2。随着ES官方的快速发展，ES也已经推出了很多新的版本，这些新版本往往伴随着一些新特性的发布以及性能的提升，为了使用到这些新特性，我们决定将ES的版本升级到7.5.2。ES版本升级会遇到API不兼容的问题，我们的解决办法是在业务和ES之间增加一层_搜索平台_来做接口兼容。此外我们在版本升级之前还需要了解一下ES-7.5.2相对于ES-1.5.2有多少性能提升，所以我们需要针对这两个版本做一下性能测试并对结果进行对比。我们使用如下的四台负载来做性能测试添加滚动条表格内的文字不折叠换行序号节点IPCPU型号CPU核数内存硬盘操作系统1172.19.66.58Intel(R) Xeon(R) CPU E5645 @2.40GHz23079520kB14GGNU/Linux 3.10.0-957.21.3.el7.x86_642172.19.66.70Intel(R) Xeon(R) CPU E5645 @2.40GHz23079524kB14GGNU/Linux 3.10.0-957.21.3.el7.x86_643172.19.66.77Intel(R) Xeon(R) CPU E5645 @2.40GHz23079524kB14GGNU&#x ...继续阅读 (72)