在 Mapping 里面,将 dynamic 参数设置成 strict 可以拒绝索引包含未知字段的文档。 此条 Tips 由 medcl 贡献。

ES集群个别节点cpu使用率达到1000%以上

Elasticsearch | 作者 ake | 发布于2023年09月07日 | 阅读数:1459

描述现象:一共21个节点的集群,时不时就有三个实例的cpu爆满,我使用top命令看最多到2000%左右,看日志显示是正在GC(日志有部分截图在下面),这导致集群不稳定,性能变差,甚至奔溃,这三个实例是再同一个物理机,每次出问题都是这三台(这三台是后面扩容的),我怀疑是否是硬件问题导致,但是看日志,并没有发现有硬件这块的错误。我重启这个物理机和集群后又恢复正常,有时需要重启3遍才能恢复正常。这个问题是没有规律的出现,有时一两个月发生一次,有时一两周发生一次。所有配置都是一样的。
 
虚拟化系统:pve 6.3 硬件配置:三星 2400 32G*10内存 E5-2690 v3 48核心cpu 万兆网卡 系统盘256G ssd
系统版本:centos7.6
ES版本:elasticsearch-6.6.2
jdk版本:openjdk version "1.8.0_262"
 
生产环境ES集群共21个节点,3个master,18个data,共7个物理机,每个物理机上面3个虚拟机,一个虚拟机运行一个es实例,每个虚拟机配置是96G内存,20核心cpu(有超配的情况) , 磁盘 8T ssd 

es5.png


es4.png

 
 
 
部分gc日志

es3.png

 
 
jvm 配置是默认的,就修改了堆内存配置为31.8G,经过测试内存指针压缩是开启的,还是32位
 
这是data节点配置文件
es1.png

 
这是master配置文件

es2.png

 
 
2023/9/18 16:20 更新
 

top1.png


 
热点线程 hot_threads(单拿出来问题节点部分)


::: {node-10-0-16-112}{5jaJrmXoQvyqspRYYmoUJw}{nSVycusZS_GKqDxqvhVpAg}{10.0.16.112}{10.0.16.112:9300}{ml.machine_memory=101379706880, rack=gz08, xpack.installed=true, ml.max_open_jobs=20, ml.enabled=true}
   Hot threads at 2023-09-18T07:52:17.790, interval=500ms, busiestThreads=3, ignoreIdleThreads=true:
   
   65.0% (325.1ms out of 500ms) cpu usage by thread 'elasticsearch[node-10-0-16-112][transport_worker][T#8]'
     2/10 snapshots sharing following 6 elements
       io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:656)
       io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:556)
       io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:510)
       io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:470)
       io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909)
       java.lang.Thread.run(Thread.java:750)
   
   58.1% (290.5ms out of 500ms) cpu usage by thread 'elasticsearch[node-10-0-16-112][transport_worker][T#7]'
     2/10 snapshots sharing following 6 elements
       io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:656)
       io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:556)
       io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:510)
       io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:470)
       io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909)
       java.lang.Thread.run(Thread.java:750)
     4/10 snapshots sharing following 9 elements
       sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
       sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
       sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
       sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
       sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
       io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:765)
       io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:413)
       io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909)
       java.lang.Thread.run(Thread.java:750)
     unique snapshot
       sun.nio.ch.NativeThread.current(Native Method)
       sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466)
       io.netty.channel.socket.nio.NioSocketChannel.doWrite(NioSocketChannel.java:405)
       io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:938)
       io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.flush0(AbstractNioChannel.java:360)
       io.netty.channel.AbstractChannel$AbstractUnsafe.flush(AbstractChannel.java:905)
       io.netty.channel.DefaultChannelPipeline$HeadContext.flush(DefaultChannelPipeline.java:1396)
       io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:776)
       io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:768)
       io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:749)
       io.netty.handler.logging.LoggingHandler.flush(LoggingHandler.java:265)
       io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:776)
       io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:768)
       io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:749)
       io.netty.channel.ChannelDuplexHandler.flush(ChannelDuplexHandler.java:117)
       io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:776)
       io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:768)
       io.netty.channel.AbstractChannelHandlerContext.access$1500(AbstractChannelHandlerContext.java:38)
       io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.write(AbstractChannelHandlerContext.java:1152)
       io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.run(AbstractChannelHandlerContext.java:1075)
       io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
       io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
       io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:474)
       io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909)
       java.lang.Thread.run(Thread.java:750)


 
火焰图无法上传附件,先截图看看

es6.png

 
启动日志:

es-r1.png


es-r2.png


es-r3.png


es-r4.png


es-r5.png

 
2023/9/21日更新
刚启动就GC了

r1.png


从其他正常节点ping主机点延迟确实是要少一点,但是这一点是否造成这么大得影响?
r2.png


r3.png


 劳烦各路大佬相助!!!
还需其他信息或建议可以留言,再次感谢大家!!
已邀请:

emmning - for learn you know

赞同来自:

问题节点的火焰图有吗

liangcw6 - ES

赞同来自:

1、查看es的hot_thread
2、硬件问题,写入性能
3、分片分布不均匀

caryliang - es使用工程师

赞同来自:

监控图呢?

ake

赞同来自:

非常感谢各位大佬胡回复!!!在社区发现类似的帖子,我跟他的区别是,我发生故障的节点是固定的。等类似问题再次发生的时候我会更新火焰图上来
类似故障帖:https://elasticsearch.cn/question/13045

ake

赞同来自:

最近发现重启故障节点机器时候发现,刚启动就开始GC了,甚至在我将数据迁移后,节点没有数据的情况下也是如此

Charele - Cisco4321

赞同来自:

你发的hotThreads信息,看不出什么来啊,好像cpu占用也不高啊。
 
除了GC警告,还有一些其它的

这是用来检测master是不是正常,
这里,它发了一个ping给master,竟然要35秒,显然是超时了。
这是它刚启动时候吧,应该不会是GC之类的问题引起的
 
看看此节点和master之间的通讯呢
 
 

Charele - Cisco4321

赞同来自:

可以看出,ping的时候差别还是很明显的。
不确定这是不是问题根源,
这种差别,最找出原因最好找出来,找不出来就算了。
 
你可以在问题物理机上,新起两个虚拟机(两个ES)实例,
让它们两个组成一个ES集群(和现有的无关),
(你应该能明白我的意思)
 
看看它们两个上面,这种怪像是不是有
 
如果有,至少缩小在这台物理机上面(硬件或软件)
 

要回复问题请先登录注册