From 06949d62db0ea87c48f9ce1e45516a34815b5efe Mon Sep 17 00:00:00 2001 From: Boaz Leskes Date: Wed, 3 Jun 2015 18:47:44 +0200 Subject: [PATCH] Reduce shard inactivity timeout to 5m To better distribute the memory allocating to indexing, the IndexingMemoryController periodically checks the different shard for their last indexing activity. If no activity has happened for a while, the controller marks the shards as in active and allocated it's memory buffer budget (but a small minimal budget) to other active shards. The recently added synced flush feature (#11179, #11336) uses this inactivity trigger to attempt as a trigger to attempt adding a sync id marker (which will speed up future recoveries). We wait for 30m before declaring a shard inactive. However, these days the operation just requires a refresh and is light. We can be stricter (and 5m) increase the chance a synced flush will be triggered. Closes #11479 --- docs/reference/indices/flush.asciidoc | 4 ++-- .../indices/memory/IndexingMemoryController.java | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/reference/indices/flush.asciidoc b/docs/reference/indices/flush.asciidoc index 118a68b712833..3ee2601bb3805 100644 --- a/docs/reference/indices/flush.asciidoc +++ b/docs/reference/indices/flush.asciidoc @@ -50,7 +50,7 @@ POST /_flush === Synced Flush Elasticsearch tracks the indexing activity of each shard. Shards that have not -received any indexing operations for 30 minutes are automatically marked as inactive. This presents +received any indexing operations for 5 minutes are automatically marked as inactive. This presents an opportunity for Elasticsearch to reduce shard resources and also perform a special kind of flush, called `synced flush`. A synced flush performs a normal flush, then adds a generated unique marker (sync_id) to all shards. @@ -117,7 +117,7 @@ which returns something similar to: === Synced Flush API The Synced Flush API allows an administrator to initiate a synced flush manually. This can be particularly useful for -a planned (rolling) cluster restart where you can stop indexing and don't want to wait the default 30 minutes for +a planned (rolling) cluster restart where you can stop indexing and don't want to wait the default 5 minutes for idle indices to be sync-flushed automatically. While handy, there are a couple of caveats for this API: diff --git a/src/main/java/org/elasticsearch/indices/memory/IndexingMemoryController.java b/src/main/java/org/elasticsearch/indices/memory/IndexingMemoryController.java index d23c872332667..e182e0df74516 100644 --- a/src/main/java/org/elasticsearch/indices/memory/IndexingMemoryController.java +++ b/src/main/java/org/elasticsearch/indices/memory/IndexingMemoryController.java @@ -116,7 +116,7 @@ public IndexingMemoryController(Settings settings, ThreadPool threadPool, Indice this.minShardTranslogBufferSize = componentSettings.getAsBytesSize("min_shard_translog_buffer_size", new ByteSizeValue(2, ByteSizeUnit.KB)); this.maxShardTranslogBufferSize = componentSettings.getAsBytesSize("max_shard_translog_buffer_size", new ByteSizeValue(64, ByteSizeUnit.KB)); - this.inactiveTime = componentSettings.getAsTime("shard_inactive_time", TimeValue.timeValueMinutes(30)); + this.inactiveTime = componentSettings.getAsTime("shard_inactive_time", TimeValue.timeValueMinutes(5)); // we need to have this relatively small to move a shard from inactive to active fast (enough) this.interval = componentSettings.getAsTime("interval", TimeValue.timeValueSeconds(30));