# Performance Issues and timeouts with Elasticsearch

**URL:** <https://discuss.elastic.co/t/performance-issues-and-timeouts-with-elasticsearch/67008>\
**Category:** Elasticsearch\
**Created:** [November 23, 2016, 4:20pm UTC](https://discuss.elastic.co/t/performance-issues-and-timeouts-with-elasticsearch/67008 "2016-11-23T16:20:42Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![nick.e](https://avatars.discourse-cdn.com/v4/letter/n/8dc957/32.png) [@nick.e](https://discuss.elastic.co/u/nick.e)\
**Post date:** [November 23, 2016, 4:20pm UTC](https://discuss.elastic.co/t/performance-issues-and-timeouts-with-elasticsearch/67008/1 "2016-11-23T16:20:42Z")

</div>

Hello together,

I'm facing strange performance issues the last days.

Following my development-cluster-setup:

- Single Node
- 12GB RAM
- 4 Cores
- Spinning Disks
- a total of 45Million (~40GB of data) Documents spread across 80 indexes and 80 shards
- Four different daily indexes, with data from 100MB up to 3GB

I allocated 6GB of RAM to JVM Heap.  
Because this installation is to get to know with the elk stack, also logstash and kibana are running on that machine.

Now my problem: When opening a Dashboard (Last 3Days) which includes visualisations with cross-index-searches, Elasticsearch is not reachable after a time. Seems like it is hard working, but in top neither CPU, nor RAM or IO-Wait have too high values. The elasticsearch log also doesn't throw any error, but Kibana runs in its timeout (in my case 120s)  
Another interesting fact is, that elasticsearch can not be stopped after this freeze and also the query  
`curl -XGET localhost:9200` returns nothing (it waits for response)

 ![](https://us1.discourse-cdn.com/elastic/original/2X/2/2f02c23cd1ee731026413d6b547d6e9040c7471c.png)

The picture shows the moment when elasticsearch is freezing.

Well, of course this is not much information, but maybe anyone has a hint what I could improve or what I can check to find the error. Maybe the hardware used for this amount of data is too bad?

---

<div class="post-metadata">

**Author:** ![nick.e](https://avatars.discourse-cdn.com/v4/letter/n/8dc957/32.png) [@nick.e](https://discuss.elastic.co/u/nick.e)\
**Post date:** [November 24, 2016, 4:26pm UTC](https://discuss.elastic.co/t/performance-issues-and-timeouts-with-elasticsearch/67008/2 "2016-11-24T16:26:03Z")

</div>

Today I reindexed all Indexes with more than one primary shard. Now every Index (including the system indexes) has one primary shard.

After that the system was stable.  
Of course, when we go productive with a multi-node-cluster, I'll change it back to two primary shards.

A strange fact is, that when I use the Reporting Tool, a new Index with five primary shards is created. Then elasticsearch freezes again. But when I create a second report, which is stored in the same index, then it does not freeze.

I don't know wether it has something to do with the shard-count, or maybe with something like garbage collection.

---

<div class="post-metadata">

**Author:** ![anhlqn](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/anhlqn/32/5454_2.png) [@anhlqn](https://discuss.elastic.co/u/anhlqn)\
**Post date:** [November 24, 2016, 6:09pm UTC](https://discuss.elastic.co/t/performance-issues-and-timeouts-with-elasticsearch/67008/3 "2016-11-24T18:09:06Z")

</div>

With 40GB of data, 80 indexes and 80 shards may be way too much compared to 6GB of JVM heap. Try to reindex 40 GB of data into 1 index with 2 to 4 primary shards and see if it helps. The average size of my indexes is 100 GB.

---

<div class="post-metadata">

**Author:** ![nick.e](https://avatars.discourse-cdn.com/v4/letter/n/8dc957/32.png) [@nick.e](https://discuss.elastic.co/u/nick.e)\
**Post date:** [November 28, 2016, 10:31am UTC](https://discuss.elastic.co/t/performance-issues-and-timeouts-with-elasticsearch/67008/4 "2016-11-28T10:31:16Z")

</div>

I was a little confused that sometimes it runs like a charm and sometimes these freezes are happening.  
I found out (or at least it seems to be the reason) that when I log in with the built-in "elastic" user, everything works and the Dashboards load as fast as expected. But as soon as I log in with my Domain-User (connected via an active-directory realm) it freezes every time.

Here some additional information:

1. role\_mapping.yml:

> superuser:
> 
> - "cn=my\_name,ou=my\_ou,dc=path\_to,dc=my,dc=domain"

1. The authentication realm-chain looks like this:

> ```
> xpack:
> security:
> authc:
> realms:
> native:
> type: native
> order: 0
> active_directory:
> type: active_directory
> order: 1
> domain_name: my_domain
> url: ldap://my_ldap_server
> unmapped_groups_as_roles: true
> 
> ```

1. In the elasticsearch.log (with cluster-wide-loglevel:debug) it continously tries to

> [2016-11-28T11:10:03,058][DEBUG][o.e.x.s.a.s.NativeRolesStore] [de-elk01] attempting to load role [**ROLE**] from index

Where **ROLE** is any group in which my Active-Directory Account belongs to. This event is triggered about 5000 times a second. Of course, not all those groups are configured as roles in x-pack (because some groups are to manage other applications)

---

<div class="post-metadata">

**Author:** ![nick.e](https://avatars.discourse-cdn.com/v4/letter/n/8dc957/32.png) [@nick.e](https://discuss.elastic.co/u/nick.e)\
**Post date:** [December 14, 2016, 6:30am UTC](https://discuss.elastic.co/t/performance-issues-and-timeouts-with-elasticsearch/67008/5 "2016-12-14T06:30:36Z")

</div>

Here the solution: The setting **unmapped\_groups\_as\_roles: true** in the elasticsearch.yml caused the problem. I don't know why this happened, but after setting it to false, everything works like expected.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 11, 2017, 6:31am UTC](https://discuss.elastic.co/t/performance-issues-and-timeouts-with-elasticsearch/67008/6 "2017-01-11T06:31:00Z")

</div>

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