Problem with maxThreadCount and maxMergeCount

[willyaranda_vonage (Guillermo)]

Hi!

We are using curator to change the maxMergeCount to 1 when our indexes are in warm (spinning disks) machines.

Today, I've seen that we have an error:

2019-01-09 09:34:41,478 DEBUG elasticsearch log_request_fail:110 < {"error":{"root_cause":[{"type":"remote_transport_exception","reason":"[xxxx-node-xxx][ip:9300][indices:admin/settings/update]"}],"type":"illegal_argument_exception","reason":"maxThreadCount (= 10) should be <= maxMergeCount (= 6)"},"status":400}

I'm trying to change both to 10 (so the condition match), but it sends me that error even with using curator.

Can you help me?

Thanks!

[theuntergeek (Aaron Mildenstein)]

Do the warm nodes have fewer cores? This is a thread count issue, and it's telling you that 10 is too high for the number of cores/processors available. It appears that the maximum allowable on this box is 6.

[willyaranda_vonage (Guillermo)]

Hi!

This indexes are still on hot nodes, because there were not moved because this error. They have 32 cores (and 8 the warm ones).

Is there a fix where I can set everything to 1? If I try it, it gives me an error, even if this is the lowest value possible.

BTW, using ES 5.1.2

[theuntergeek (Aaron Mildenstein)]

I would not recommend changing the maxThreadCount. Changing maxMergeCount is still not something I would recommend, but if you are doing that, I would not try to make it large at all, especially not if you have spinning disks. Too many concurrent merges is just not recommended, as the I/O load can be very taxing.

[willyaranda_vonage (Guillermo)]

We are changing it just when our indexes are being moved from SSD to spinning, so we set them to 1, because there we force_merge to get less segments.

The problem that we have is that it's set to 10 (we don't know why) today, and we cannot lower that value, and indexing seems to fail because of this.

Any clue to force the values to the default would be really helpful.

Thanks!