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

参考URL

• Kibanaの運用で注意すること - Carpe Diem
• fluentd -> Elasticsearch 大量データ転送でトラブル | diaspora
• Configuration
• ElasticSearchのfield data cacheについて - サナギわさわさ.json
• Field data
• Restarting a 2-node elasticsearch cluster with zero downtime - Stack Overflow
• Elasticsearchのマスタノードがダウンするとクラスタ全体がダウンする - Qiita
• elasticsearchの起動時にUnknownHostExceptionが発生した場合の対処方法 - Qiita
• ElasticSearchの運用とか (2) - なんかかきたい
• Elasticsearch導入前に気を付けておきたいこと！ - Qiita

直近で落ちた原因

本番運用中に、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

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