我正在使用elasticsearch 1.5
它在大部分时间都运行良好，但每天同时它变得疯狂，当平均值约为3-5％时，CPU％达到~70％有超级服务器，32GB保留用于堆mem，交换它是锁定并清除缓存并不能解决问题（它不会删除堆内存）
设置：
3个服务器（节点）32个核心和128GB RAM 2个桶（索引），一个有大约1800万个文档（这个没有接收更新，通常只是索引新文档）另一个有大约7-8百万个文档，但我们不断用它更新搜索删除和索引来轰炸它
我们的结构的最佳分布是每个节点只有1个不带副本的分片，我们可以在几秒钟内关闭一半的数据，一旦服务器再次上线就会恢复，而且这个过程足够快，因为它不需要重新定位任何东西。以前我们曾经有3个碎片和1个副本，但上面提到的问题也是如此，所以很容易弄清楚问题与分布无关。
我已经尝试过的事情，
合并，我尝试使用Optimize API尝试减少计划合并的负担，但实际上合并过程需要大量的R / W磁盘，但它不会显着影响mem或CPU负载。
Flushing，我尝试使用long和shot间隔进行刷新，结果没有任何改变，因为刷新会直接影响合并过程，如上所述，合并过程不会占用大量的CPU或内存使用量。
管理缓存，手动清除缓存，但似乎不会将CPU加载到正常状态，即使是暂时也没有。
这是elasticsearch.yml配置的大部分内容
# Force all memory to be locked, forcing the JVM to never swap
bootstrap.mlockall: true
## Threadpool Settings ##
# Search pool
threadpool.search.type: fixed
threadpool.search.size: 20
threadpool.search.queue_size: 200
# Bulk pool
threadpool.bulk.type: fixed
threadpool.bulk.size: 60
threadpool.bulk.queue_size: 3000
# Index pool
threadpool.index.type: fixed
threadpool.index.size: 20
threadpool.index.queue_size: 1000
# Indices settings
indices.memory.index_buffer_size: 30%
indices.memory.min_shard_index_buffer_size: 12mb
indices.memory.min_index_buffer_size: 96mb
# Cache Sizes
indices.fielddata.cache.size: 30%
#indices.fielddata.cache.expire: 6h #will be depreciated & Dev recomend not to use it
indices.cache.filter.size: 30%
#indices.cache.filter.expire: 6h #will be depreciated & Dev recomend not to use it
# Indexing Settings for Writes
index.refresh_interval: 30s
#index.translog.flush_threshold_ops: 50000
#index.translog.flush_threshold_size: 1024mb
index.translog.flush_threshold_period: 5m
index.merge.scheduler.max_thread_count: 1
当服务器占用很大的CPU时
！[当服务器在CPU-1上占用很大的时候] [1] ！[当服务器在CPU-2上占用很大的时候] [3]
当服务器处于正常状态时
！[[当服务器处于正常状态时-1] [2] ！[当服务器处于正常状态时-2] [4]
我将非常感谢能够指出正确方向摆脱这种行为的任何帮助或讨论
似乎我无法发布图片...联系我，我会给他们发电子邮件 提前谢谢..
问候，
丹尼尔