记一次Elasticsearch OOM的优化过程——基于segments force merge 和 store type 转为 niofs

首选,说明笔者的机器环境(不结合环境谈解决方案都是耍流氓): cpu 32核,内存128G,非固态硬盘: RAID0 (4T * 6),单节点,数据量在700G到1800G,索引15亿~21亿。敖丙大人,在蘑菇街,集群分片,固态硬盘比不起。

转载请注明出处:https://www.cnblogs.com/NaughtyCat/p/elasticsearch-OOM-optimize-story.html 

业务场景:

保存7天索引,每天有400G。发现ES时不时的OOM,和重启。当索引超过500G的时候,ES重启到加载所有分片,时间约30分钟到1小时。

题外话,ES OOM 会生成  .hprof 文件,如下图(作者【CoderBaby】):

jhat来分析OOM堆转储文件,具体命令如: jhat -port 7401 -J-Xmx4G java_pid19546.hprof

解决办法:

  • 改文件存储类型,减少内存占用

设置存储类型为:“nifos” ,即: "index.store.type": "niofs" (原来为“mmapfs”,详见附2)。mmapfs — index映射到内存,niofs — 并发多线程以NIO的方式读取index文件。

效果:在600G左右的索引,5天索引,确实没有了OOM。但一旦增大到7个索引,就不行了。用jstat命令,即:stat -gcutil 6811 (ES的PID)查看ES的jvm,如下图:

O: Old space utilization as a percentage of the space‘s current capacity (老年代空间占用率)。O最高达到79,就往下降,原来为存储类型为“mmapfs”,O很容易就飙到100.

  • 关闭暂时不用的索引,减少打开索引的数量

关闭索引(文件仍然存在于磁盘,只是释放掉内存,需要的时候可重新打开)。设置打开索引参数: "__es.maxPermanentlyOpenIndices":4 (最大打开索引:7改为4)。

  • 扩大堆内存

设置堆大小,从15G提高到30G,即: -Xms30g -Xmx30g (注意:最大不要超过物理内存的 %50

  • forcemerge

设置merge时最大的线程数:index.merge.scheduler.max_thread_count。固态硬盘——默认最大值  Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2)) ,普通旋转磁盘——设置为1

笔者机器上,单merge 线程,300G的索引耗时:7个小时

优化效果: term 单条件查询,查询时间从10秒多提高到3秒多,索引减少约%2.85,减少4000多万,具体如下表:

index total_segments_berfore_merge total_segments_after_merge query_IP_after(seconds)   query_IP_after(seconds)  decrease(count/percentage)
pcap_flow-2019-12-09  1412695374 137249867 10 3.6 40196703/ %2.845

可通过命令查看,分片的情况

force merge的restful API:

curl -X POST "localhost:9200/pcap_flow-2019-12-11/_forcemerge?max_num_segments=2"

说明:

1)max_num_segments, 设置最大segement数量,数量越小,查询速度提高越明显,但merge耗时越长

2)全部merge,不加索引ID,则如下:

curl -X POST "localhost:9200/_forcemerge?"

3)串行merge,如果同时merge多个,后面的会被阻塞,知道第一个merge完成为止

4)restful api 查看_segments,如下:

curl -X GET "localhost:9200/_cat/segments?v&pretty"

效果如下图:

题外话,如果贵司银子多,可以集群分片,搞SSD,否则只有结构优化,这一招。

 附:

1)官网  index force merge说明: https://www.elastic.co/guide/en/elasticsearch/reference/7.4/indices-forcemerge.html

2) ES 存储类型: https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html

3)merge 线程数: https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-merge.html

4)磁盘阵列RAID: https://zh.wikipedia.org/wiki/RAID

5)关于索引合并的统计分析: http://openskill.cn/article/375

*****************************************************************************************************

精力有限,想法太多,专注做好一件事就行

  • 我只是一个程序猿。5年内把代码写好,技术博客字字推敲,坚持零拷贝和原创
  • 写博客的意义在于打磨文笔,训练逻辑条理性,加深对知识的系统性理解;如果恰好又对别人有点帮助,那真是一件令人开心的事

*****************************************************************************************************

原文地址:https://www.cnblogs.com/NaughtyCat/p/elasticsearch-OOM-optimize-story.html

时间: 2024-10-01 11:51:18

记一次Elasticsearch OOM的优化过程——基于segments force merge 和 store type 转为 niofs的相关文章

【夯实Mysql基础】记一次mysql语句的优化过程!

1. [事件起因] 今天在做项目的时候,发现提供给客户端的接口时间很慢,达到了2秒多,我第一时间,抓了接口,看了运行的sql,发现就是 2个sql慢,分别占了1秒多. 一个sql是 链接了5个表同时使用了 2个 order by和 1个limit的分页 sql. 一个sql是上一个sql的count(*),即链接了5个表,当然没有limit了(取总数). 2. [着手优化] 1)[优化思路] 第一条是 做client调用 service层的数据缓存 第二条就是 优化sql本身. 这里着重讲一下

【夯实Mysql基础】记一次mysql语句的优化过程

1. [事件起因] 今天在做项目的时候,发现提供给客户端的接口时间很慢,达到了2秒多,我第一时间,抓了接口,看了运行的sql,发现就是 2个sql慢,分别占了1秒多. 一个sql是 链接了5个表同时使用了 2个 order by和 1个limit的分页 sql. 一个sql是上一个sql的count(*),即链接了5个表,当然没有limit了(取总数). 2. [着手优化] 1)[优化思路] 第一条是 做client调用 service层的数据缓存 第二条就是 优化sql本身. 这里着重讲一下

记一次内存泄露优化过程

背景 项目目前存在使用久了或者重复打开关闭某个页面,内存会一直飙升,居高不下,频繁发生GC.静置一段时间后,情况有所改善,但是问题依旧明显,如图1-1.1-2. 图1-1.操作时的内存使用情况 图1-2.静置时的内存使用情况 如上图1-1,是通过Android Studio查看内存(灰色)和CPU(红色)使用情况,可以看出内存有发生抖动并且是处于比较高的状态,再者,从logcat可以看到一直发生GC,如下图1-3: 图1-3. 出现这些情况,是有很多因素造成的,最主要的原因是发生了内存泄露:页面

记一次OOM查询处理过程

记一次OOM查询处理过程 问题的爆出及分析排查现场 排查后的解决方案 项目的jvm参数 总结 一.问题的爆出及分析排查现场 服务偶尔会出现不可用的情况,导致出现time out,然后我迅速登录现场,直接查看当时的gc日志,不废话,直接上图 通过这个图可以发现在10点7分.8分的时候频繁Full GC,但是GC之后 年轻代,老年代并没有少.并且Full GC时长5s8多,造成stop-the-world5s8,因此应用程序会出现无影响.再贴一张图 通过这个可以看到内存慢慢的通过GC降下来了 根据这

网站基于ElasticSearch搜索的优化笔记 PHP

基本情况就是,媒体.试题.分类,媒体可能有多个试题,一个试题可能有多个分类,分类为三级分类加上一个综合属性.通过试题名称.分类等搜索查询媒体. 现在的问题为,搜索结果不精确,部分搜索无结果,ES的数据结构不满足搜索需求.解决方案就是,重构ES数据结构,采用父子关系的方式,建立media和question两个type. 全程使用https://github.com/mobz/elasticsearch-head,这个进行ES的管理和查看,很方便. 从ES的说明可以看出,ES是面向文档,其实所有的数

高斯模糊算法的全面优化过程分享(二)。

      相关链接: 高斯模糊算法的全面优化过程分享(一) 在高斯模糊算法的全面优化过程分享(一)一文中我们已经给出了一种相当高性能的高斯模糊过程,但是优化没有终点,经过上一个星期的发愤图强和测试,对该算法的效率提升又有了一个新的高度,这里把优化过程中的一些心得和收获用文字的形式记录下来. 第一个尝试   直接使用内联汇编替代intrinsics代码(无效) 我在某篇博客里看到说intrinsics语法虽然简化了SSE编程的难度,但是他无法直接控制XMM0-XMM7寄存器,很多指令中间都会用内

记一次SQLServer的分页优化兼谈谈使用Row_Number()分页存在的问题

最近有项目反应,在服务器CPU使用较高的时候,我们的事件查询页面非常的慢,查询几条记录竟然要4分钟甚至更长,而且在翻第二页的时候也是要这么多的时间,这肯定是不能接受的,也是让现场用SQLServerProfiler把语句抓取了上来. 用ROW_NUMBER()进行分页 我们看看现场抓上来的分页语句: select top 20 a.*,ag.Name as AgentServerName,,d.Name as MgrObjTypeName,l.UserName as userName from

记一次公司仓库服务器死锁过程

记一次公司仓库服务器死锁过程 仓库拣货卡死,排查了数据库的很多地方,都没有头绪,最后到SQL Server 错误日志里查看,终于发现了蛛丝马迹 EXEC xp_readerrorlog 0,1,NULL,NULL,'2015-09-21','2015-10-10','DESC' waiter id=process5c30e08 mode=U requestType=wait waiter-list owner id=process5c26988 mode=X owner-list keylock

Redis数据导入工具优化过程总结

Redis数据导入工具优化过程总结 背景 使用C++开发了一个Redis数据导入工具 从oracle中将所有表数据导入到redis中: 不是单纯的数据导入,每条oracle中的原有记录,需要经过业务逻辑处理, 并添加索引(redis集合): 工具完成后,性能是个瓶颈: 优化效果 使用了2个样本数据测试: 样本数据a表8763 条记录: b表940279 条记录: 优化前,a表耗时11.417s: 优化后,a表耗时1.883s: 用到的工具 gprof, pstrace,time 使用time工具