# \[SOLVED\] Thread pool for Painless aggregation **URL:** \ **Category:** Elasticsearch\ **Created:** [February 22, 2018, 4:21pm UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087 "2018-02-22T16:21:00Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![cbismuth](https://avatars.discourse-cdn.com/v4/letter/c/9e8a1a/32.png) [@cbismuth](https://discuss.elastic.co/u/cbismuth)\ **Post date:** [February 22, 2018, 4:21pm UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087/1 "2018-02-22T16:21:00Z")
Hi, We have 46% of idle CPU while executing heavy Painless aggregations. We wish we could consume this idle CPU time. Is there any thread pool to configure to do so? Thank you, Christophe ---
**Author:** ![rjernst](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rjernst/32/6363_2.png) [@rjernst](https://discuss.elastic.co/u/rjernst)\ **Post date:** [February 22, 2018, 5:14pm UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087/2 "2018-02-22T17:14:50Z")
Painless does not have it's own threadpool. It operates within the thread of whatever context is calling it. For aggregations, that would be the search threadpool. However, are your search requests being throttled? If you are running few but heavy requests, increasing the threads will not help. Instead, you probably want to find the bottleneck. For example, depending on the aggregation, memory can be a limiting factor. You can check many of the relevant stats with the [stats api](https://www.elastic.co/guide/en/elasticsearch/reference/6.2/cluster-nodes-stats.html). ---
**Author:** ![cbismuth](https://avatars.discourse-cdn.com/v4/letter/c/9e8a1a/32.png) [@cbismuth](https://discuss.elastic.co/u/cbismuth)\ **Post date:** [February 22, 2018, 5:25pm UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087/3 "2018-02-22T17:25:06Z")
Thank you, we've increased RAM and heap from 16 Go (8 Go heap) to 32 Go (16 Go heap) without any performance improvement. We profiled our searches and aggregations with Elasticsearch Java DSL profile API, but search phase is fast, aggregations are 5x slower approx. That's why we think we should increase shard count and node count. ---
**Author:** ![rjernst](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rjernst/32/6363_2.png) [@rjernst](https://discuss.elastic.co/u/rjernst)\ **Post date:** [February 22, 2018, 5:47pm UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087/4 "2018-02-22T17:47:19Z")
Increasing number of shards and nodes might help. It depends on how many shards/nodes you currently have, and again, what types of aggregations you are running. Some are more memory intensive than others. ---
**Author:** ![cbismuth](https://avatars.discourse-cdn.com/v4/letter/c/9e8a1a/32.png) [@cbismuth](https://discuss.elastic.co/u/cbismuth)\ **Post date:** [February 23, 2018, 9:33am UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087/5 "2018-02-23T09:33:43Z")
We have an indices of 10 Go with 10 000 000 documents split in 5 shards / 1 replica over 3 nodes. We plan to upgrade to 5 nodes. Besides, when we do nothing, 2 nodes out of 3 consume 10% of CPU user time. Is there any reason to do so? With half memory assigned (16 Go RAM and 8 Go heap) those two nodes consume 20% CPU user time nothing is run against the cluster. We can't find out why. We are using Elastic 6.1.1. ---
**Author:** ![Bernt\_Rostad](https://avatars.discourse-cdn.com/v4/letter/b/3ab097/32.png) [@Bernt\_Rostad](https://discuss.elastic.co/u/Bernt_Rostad)\ **Post date:** [February 23, 2018, 10:47am UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087/6 "2018-02-23T10:47:21Z")
You could try to play with [execution hint](https://www.elastic.co/guide/en/elasticsearch/reference/1.6/search-aggregations-bucket-terms-aggregation.html#search-aggregations-bucket-terms-aggregation-execution-hint) in your aggregations. Last year my company struggled with a very slow aggregation query across 100+ million documents, it took minutes to complete. I managed to improve it almost a 100-fold by setting `"execution_hint": "map"`, so it could be worth your effort. ---
**Author:** ![cbismuth](https://avatars.discourse-cdn.com/v4/letter/c/9e8a1a/32.png) [@cbismuth](https://discuss.elastic.co/u/cbismuth)\ **Post date:** [February 23, 2018, 10:48am UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087/7 "2018-02-23T10:48:12Z")
Nice, thank you Bernt! ---
**Author:** ![cbismuth](https://avatars.discourse-cdn.com/v4/letter/c/9e8a1a/32.png) [@cbismuth](https://discuss.elastic.co/u/cbismuth)\ **Post date:** [March 3, 2018, 12:48pm UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087/8 "2018-03-03T12:48:13Z")
Thank you both @rjernst and @Bernt_Rostad, we've decreased vCPU count per node and increased node count. Search thread pools are efficiently used. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [March 31, 2018, 12:48pm UTC](https://discuss.elastic.co/t/solved-thread-pool-for-painless-aggregation/121087/9 "2018-03-31T12:48:37Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.