# Indexing to two relatively large indices slows down. Any ideas? **URL:** \ **Category:** Elasticsearch\ **Created:** [September 9, 2015, 5:01pm UTC](https://discuss.elastic.co/t/indexing-to-two-relatively-large-indices-slows-down-any-ideas/28954 "2015-09-09T17:01:07Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![asharif](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/asharif/32/8545_2.png) [@asharif](https://discuss.elastic.co/u/asharif)\ **Post date:** [September 9, 2015, 5:01pm UTC](https://discuss.elastic.co/t/indexing-to-two-relatively-large-indices-slows-down-any-ideas/28954/1 "2015-09-09T17:01:07Z")
So a bit of prerequisites: 1. ES version: 1.6.0 2. On AWS cluster, 16 d2.2xlarge 3. Configured like so threadpool.bulk.type: fixed threadpool.bulk.queue\_size: 200 indices.fielddata.cache.size: 20% indices.fielddata.cache.expire: 5m indices.breaker.fielddata.limit: 40% indices.breaker.request.limit: 40% indices.breaker.total.limit: 40% index.analysis.analyzer.default.type: keyword index.number\_of\_shards: 16 index.number\_of\_replicas: 0 index.search.slowlog.threshold.query.warn: 10s index.search.slowlog.threshold.query.info: 5s index.search.slowlog.threshold.query.debug: 2s index.search.slowlog.threshold.query.trace: 500ms index.search.slowlog.threshold.fetch.warn: 1s index.search.slowlog.threshold.fetch.info: 800ms index.search.slowlog.threshold.fetch.debug: 500ms index.search.slowlog.threshold.fetch.trace: 200ms index.indexing.slowlog.threshold.index.warn: 10s index.indexing.slowlog.threshold.index.info: 5s index.indexing.slowlog.threshold.index.debug: 2s index.indexing.slowlog.threshold.index.trace: 500ms 1. Using the Java transport client we are indexing sensor data that happened in the day. 2. The documents have 45 json field (couple of which are arrays of other objects with a depth of 1) 3. We are indexing at a rate of 60-70kps 4. The index will have between 2.5-3B documents by the end of a day. Now for the problem: Sometimes we need to index to two days at the same time. As soon as we start indexing to two index with a cardinality greater than 2.5B, all indexing comes to a halt. Reducing down to a few hundred with spikes in the 50k range. Obviously this is no good for us. Any help would be appreciated. ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [September 11, 2015, 6:53am UTC](https://discuss.elastic.co/t/indexing-to-two-relatively-large-indices-slows-down-any-ideas/28954/2 "2015-09-11T06:53:15Z")
What does hot threads look like during these sorts of times? What monitoring do you have in place? ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [September 11, 2015, 7:56am UTC](https://discuss.elastic.co/t/indexing-to-two-relatively-large-indices-slows-down-any-ideas/28954/3 "2015-09-11T07:56:51Z")
One thing I am missing from your configuration settings is setting index.merge.scheduler.max\_thread\_count to 1. This is recommended when using non-SSD disks in order to reduce concurrent merging as outlined [here](https://www.elastic.co/blog/performance-considerations-elasticsearch-indexing). If your hot threads indicate a lot of merging going on during the times you have problems, this may help. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 11:50pm UTC](https://discuss.elastic.co/t/indexing-to-two-relatively-large-indices-slows-down-any-ideas/28954/4 "2017-07-05T23:50:54Z")