Edited at

EC2に立てたElasticsearchクラスタの設定を見直してみた(何度も落ちるので・・・)

More than 3 years have passed since last update.


参考URL


直近で落ちた原因

本番運用中に、SortやAggregationが繰り返されたのか、シンプルに「Out of memory error」が起きた模様。


elasticsearch.log

[2016-03-25 06:56:35,187][INFO ][monitor.jvm ] [Ch'od] [gc][old][2146478][216] duration [5s], collections [1]/[5.4s], total [5s]/[4.8m], memory [5.3gb]->[4.1gb]/[6.9gb], all_pools

{[young] [490.9kb]->[176.1mb]/[266.2mb]} {[survivor] [33.2mb]->[0b]/[33.2mb]} {[old] [5.3gb]->[3.9gb]/[6.6gb]}
[2016-03-25 07:04:58,711][WARN ][transport.netty ] [Ch'od] exception caught on transport layer [[id: 0xb644334e, /10.0.XXX.XXX:54546 => /10.0.XXX.XXX:9300]], closing connection
java.lang.OutOfMemoryError: Java heap space
at org.elasticsearch.common.netty.buffer.HeapChannelBuffer.<init>(HeapChannelBuffer.java:42)
at org.elasticsearch.common.netty.buffer.BigEndianHeapChannelBuffer.<init>(BigEndianHeapChannelBuffer.java:34)
at org.elasticsearch.common.netty.buffer.ChannelBuffers.buffer(ChannelBuffers.java:134)
at org.elasticsearch.common.netty.buffer.HeapChannelBufferFactory.getBuffer(HeapChannelBufferFactory.java:68)
at org.elasticsearch.common.netty.buffer.AbstractChannelBufferFactory.getBuffer(AbstractChannelBufferFactory.java:48)
at org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder.newCumulationBuffer(FrameDecoder.java:507)
at org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder.updateCumulation(FrameDecoder.java:345)
at org.elasticsearch.common.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:305)
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:318)
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:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)


上記の対応策含め、その他設定値を見直し


  • Elasticsearchの設定ファイルの見直し


/etc/elasticsearch/elasticsearch.yml

# メモリにフィールドのデータが無制限に載るのを制限

# これが今回の原因への対策!
indices.fielddata.cache.size: 75%
# JVM起動時にメモリを確保するようになり、JVMのヒープサイズもここで指定したサイズに固定される。
bootstrap.mlockall: true


  • システムの設定値の見直し

# コマンドで変更

# Elasticの公式サイトより確認
$ sudo sysctl -w vm.max_map_count=262144
$ sudo swapoff -a


/etc/sysctl.conf

# Elasticの公式サイトより確認

vm.max_map_count = 262144


/etc/sysconfig/elasticsearch

# Heap Size (defaults to 256m min, 1g max)

ES_HEAP_SIZE=2g (本番はもっと大きくあててます。)

# Maximum amount of locked memory
MAX_LOCKED_MEMORY=unlimited



/etc/fstab

# 「swap」を含むものすべてをコメントアウト(下記は例です。EC2だとありませんでした。)

# /dev/hda2 swap swap defaults

何か間違っているところがあれば、皆様コメントでも教えてくださいませ。mm