2015-10-06 115 views
3

烫发根空间问题,我们正在运行elasticsearch-1.5.1集群节点,我对着java.lang.OutOfMemoryError PermGen的空间问题集群在最近几天,这影响到节点上的同会沮丧。我正在重新启动特定节点才能生效。获取运行elasticsearch集群

我们试图通过给群集带来沉重的负担来找出这个问题,但不幸的是无法重现。但一些我们在生产中一次又一次地得到同样的问题。

这里是一些阳明文件配置的

index.recovery.initial_shards: 1 
index.query.bool.max_clause_count: 8192 
index.mapping.attachment.indexed_chars: 500000 
index.merge.scheduler.max_thread_count: 1 
cluster.routing.allocation.node_concurrent_recoveries: 15 
indices.recovery.max_bytes_per_sec: 50mb 
indices.recovery.concurrent_streams: 5 

内存配置

ES_HEAP_SIZE=10g 
ES_JAVA_OPTS="-server -Des.max-open-files=true" 
MAX_OPEN_FILES=65535 
MAX_MAP_COUNT=262144 

更新问题下面的配置

我怀疑merge.policy.max_merged_segment与这个问题有关。我的集群中有22个索引。为指数的merge.policy.max_merged_segment下面

  • 7指数给出具有20GB
  • 3指数已经10GB
  • 12指数已经5GB

更新与处理信息

esuser xxxxx 1 Oct03? 1-02:20:40 /usr/java/default/bin/java -Xms10g -Xmx10g -Djava.awt.headless = true -XX:+ UseParNewGC -XX:+ UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction = 75 -XX: + UseCMSInitiatingOccupancyOnly -XX:+ HeapDumpOnOutOfMemoryError -XX:+ DisableExplicitGC -Dfile.encoding = UTF-8 -server -Des.max-open-files = true -Delasticsearch -Des.pidfile =/var/es/elasticsearch.pid -Des。/usr/es/elasticsearch/lib/:/ usr/es/elasticsearch/lib/sigar/ -Des.default.path.home =/usr/es/elasticsearch -Des.default.path.logs =/es/es_logs -Des.default.path.data =/es/es_data -Des.default。 path.work =/es/es_work -Des.default.path.conf =/etc/elasticsearch org.elasticsearch.bootstrap.Elasticsearch


在我搜索时从elasticsearch集群获取的堆栈跟踪下方。但事件,而索引时间也是我得到同样的问题。根据我的观察,一些搜索/索引操作会增加PermGen,如果即将进行的操作尝试使用PermGen空间的话。

[2015-10-03 06:45:05,262][WARN ][transport.netty   ] [es_f2_01] Message not fully read (response) for [19353573] handler [email protected]1a25e37, error [true], resetting 
[2015-10-03 06:45:05,262][DEBUG][action.search.type  ] [es_f2_01] [product_index][4], node[GoUqK7csTpezN5_xoNWbeg], [R], s[INITIALIZING]: Failed to execute [[email protected]] lastShard [true] 
org.elasticsearch.transport.RemoteTransportException: Failed to deserialize exception response from stream 
Caused by: org.elasticsearch.transport.TransportSerializationException: Failed to deserialize exception response from stream 
    at org.elasticsearch.transport.netty.MessageChannelHandler.handlerResponseError(MessageChannelHandler.java:176) 
    at org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:128) 
    at org.elasticsearch.common.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) 
    at org.elasticsearch.common.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) 
    at org.elasticsearch.common.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) 
    at org.elasticsearch.common.netty.channel.Channels.fireMessageReceived(Channels.java:296) 
    at org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) 
    at org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) 
    at org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303) 
    at org.elasticsearch.common.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) 
    at org.elasticsearch.common.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) 
    at org.elasticsearch.common.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) 
    at org.elasticsearch.common.netty.channel.Channels.fireMessageReceived(Channels.java:268) 
    at org.elasticsearch.common.netty.channel.Channels.fireMessageReceived(Channels.java:255) 
    at org.elasticsearch.common.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) 
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108) 
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337) 
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) 
    at org.elasticsearch.common.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) 
    at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) 
    at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
    at java.lang.Thread.run(Thread.java:722) 
Caused by: java.lang.OutOfMemoryError: PermGen space 

有什么可以帮助我解决这个问题。谢谢

+0

这对Elasticsearch来说是不常见的。这是什么ES版本?您是否在生产和测试环境中具有相同的设置? ES的内存设置是什么?运行'ps -ef | grep elasticsearch'并提供结果。 –

+0

@AndreiStefan新增了grep的详细过程,我已经在问题中分享了ES版本,ES的内存设置。 &我在测试env时与生产相比没有确切的配置。 –

+0

这是异常的完整堆栈跟踪吗?还有根异常吗? –

回答

0

最好的解决方案是使用“Java 8”JVM。

尽管您可以修改Java 7 JVM使用的堆的数量(通过设置-XX:MaxPermSize = ...如果您使用的是Oracle JVM),但如果您只是将JVM升级到版本8,那么您甚至不需要调整permgen大小。

这是因为在JVM 8,PermGen的大小股份堆在非分区方式,这意味着你只会耗尽PermGen的空间,当你用完了堆。

+0

感谢您的信息。在生产环境中升级到JAVA8将修复PermGen问题,但现在无法升级,我可以明确设置PermGenSize。即使我想知道根本原因并为此提供解决方案。 –

+0

根本原因在于您正在使用HotSpot JVM,它通过将大量使用的代码编译为机器代码来加快运行速度,从而优化代码。这是期望的行为,而不是错误。问题是,经过一段时间之后,它可能会发现有太多的代码需要优化,以至于空间不足以存储优化的机器代码。在较旧的JVM版本中,此代码只能存储在JVM内的预先分配的内存区域中。在较新的JVM版本中,它存储在Heap上。 –

+0

谢谢Edwin ...我同意你的观点Edwin,它纯粹的JVM内存利用率问题。 PermGen通常是将类文件加载到mem中,我希望在config/app/settings/process中有一些mem泄漏点,可能会在mem中再次加载这些类,并且无法从mem中卸载这些类。我仍然试图找出那个mem漏洞的位置。 –