# Bulk indexing causes management threadpool queue to skyrocket

**URL:** https://discuss.elastic.co/t/bulk-indexing-causes-management-threadpool-queue-to-skyrocket/217852
**Category:** Elasticsearch
**Created:** [February 4, 2020, 4:58pm UTC](https://discuss.elastic.co/t/bulk-indexing-causes-management-threadpool-queue-to-skyrocket/217852 "2020-02-04T16:58:59Z")
**Posts on this page:** 1
**Showing post:** 19

<div class="post-metadata">

### Author: ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)
#### Post date: [February 6, 2020, 11:43am UTC](https://discuss.elastic.co/t/bulk-indexing-causes-management-threadpool-queue-to-skyrocket/217852/19 "2020-02-06T11:43:14Z")

</div>

Good catch, yes, that'd explain it. 5 cluster-wide stats calls per second is definitely on the abusive side. When you weren't indexing it looks like you had enough resources (particularly, IO bandwidth) to cope with the monitoring load, but it seems that the extra load from indexing pushed it over the edge.

I think we can generally do better here, optimisations of the completion stats calculation aside, so I opened [https://github.com/elastic/elasticsearch/issues/51992](https://github.com/elastic/elasticsearch/issues/51992) to discuss higher-level protection against this.

---

_[View the full topic](https://discuss.elastic.co/t/bulk-indexing-causes-management-threadpool-queue-to-skyrocket/217852)._