请提供参考的网址

• 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的重复执行，简单地导致了“内存溢出错误”的发生。

[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の設定ファイルの見直し

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

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

# コマンドで変更
# Elasticの公式サイトより確認
$ sudo sysctl -w vm.max_map_count=262144
$ sudo swapoff -a

# Elasticの公式サイトより確認
vm.max_map_count = 262144

# Heap Size (defaults to 256m min, 1g max)
ES_HEAP_SIZE=2g (本番はもっと大きくあててます。)

# Maximum amount of locked memory
MAX_LOCKED_MEMORY=unlimited

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

如果有任何錯誤之處，請大家在評論中告訴我。