Couldn't force merge index - any hint on where to troubleshoot



I got merging problems earlier, so I made indices smaller by changing retention settings. That lead to problems with a large number of shards (I have around 10000 now in my ES cluster). So I decided to come back towards larger indices, based on the advice found in some ES forum; sizing a shard to about 50G maximum. Now I got this index merge problem again. Any idea on where to start digging about these? What parameters would be of interest?

There are no errors in ES logs, but this is found in Graylog master node log: This is about 1 hour after index cycling.

2017-09-05T04:00:38.621+03:00 ERROR [SystemJobManager] Unhandled error while running SystemJob <3ff00ff0-91cd-11e7-a7a3-0050568617f3> []
org.graylog2.indexer.ElasticsearchException: Couldn't force merge index graylog_1543
        at org.graylog2.indexer.cluster.jest.JestUtils.execute( ~[graylog.jar:?]
        at org.graylog2.indexer.indices.Indices.optimizeIndex( ~[graylog.jar:?]
        at ~[graylog.jar:?]
        at$ [graylog.jar:?]
        at com.codahale.metrics.InstrumentedScheduledExecutorService$ [graylog.jar:?]
        at java.util.concurrent.Executors$ [?:1.8.0_141]
        at [?:1.8.0_141]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201( [?:1.8.0_141]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ [?:1.8.0_141]
        at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:1.8.0_141]
        at java.util.concurrent.ThreadPoolExecutor$ [?:1.8.0_141]
        at [?:1.8.0_141]
Caused by: Read timed out
        at Method) ~[?:1.8.0_141]
        at ~[?:1.8.0_141]
        at ~[?:1.8.0_141]
        at ~[?:1.8.0_141]
        at ~[graylog.jar:?]
        at ~[graylog.jar:?]
        at ~[graylog.jar:?]
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead( ~[graylog.jar:?]
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead( ~[graylog.jar:?]
        at ~[graylog.jar:?]
        at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader( ~[graylog.jar:?]
        at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader( ~[graylog.jar:?]
        at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse( ~[graylog.jar:?]
        at org.apache.http.protocol.HttpRequestExecutor.execute( ~[graylog.jar:?]
        at org.apache.http.impl.execchain.MainClientExec.execute( ~[graylog.jar:?]
        at org.apache.http.impl.execchain.ProtocolExec.execute( ~[graylog.jar:?]
        at org.apache.http.impl.execchain.RetryExec.execute( ~[graylog.jar:?]
        at org.apache.http.impl.execchain.RedirectExec.execute( ~[graylog.jar:?]
        at org.apache.http.impl.client.InternalHttpClient.doExecute( ~[graylog.jar:?]
        at org.apache.http.impl.client.CloseableHttpClient.execute( ~[graylog.jar:?]
        at org.apache.http.impl.client.CloseableHttpClient.execute( ~[graylog.jar:?]
        at io.searchbox.client.http.JestHttpClient.executeRequest( ~[graylog.jar:?]
        at io.searchbox.client.http.JestHttpClient.execute( ~[graylog.jar:?]
        at org.graylog2.indexer.cluster.jest.JestUtils.execute( ~[graylog.jar:?]
        ... 11 more

(Jochen) #2

The Elasticsearch cluster takes longer to perform the force merge of the index segments than the configured request timeout.

You have multiple options how to fix that:


Thanks! This is great. I did not notice that this option is now available - my old server.conf did not have that.

I’ll use a timeout of 11h for 12h cycling; I think there is no hurry in that optimization.

(Jochen) #4

elasticsearch_index_optimization_timeout can be used to configure the request timeout for the force-merge request.

If the completion of a force-merge request takes 11 hours to complete, you have serious problems with the performance of your Elasticsearch cluster.

(Jan Doberstein) #5

to be honest

my old server.conf did not have that.

that is why one would read the update announcement / the update documentation where such new or removed settings are explained.


It will probably not take that long. We’ll see that later. I just used that now to see what happens. The reality is that I don’t see any performance change in UI, whether the optimization is going on, or not. ES seems to be doing it in a leisurely way in the background.


Indeed. I have read the upgrade notes from the manual (e.g. . These documents do tell which settings to remove from the config. Is there another place worth looking for when upgrading, or did I just not see?

Btw. my intention was not to criticize you with my comment on the old server.conf file.

(Jochen) #8

The elasticsearch_index_optimization_timeout setting was already added in Graylog 2.2.0 and is only mentioned in the Graylog 2.2.0 changelog.

(system) closed #9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.