# Understanding Elasticsearch performance and correlation with hardware specs **URL:** \ **Category:** Elasticsearch\ **Created:** [November 20, 2016, 6:33pm UTC](https://discuss.elastic.co/t/understanding-elasticsearch-performance-and-correlation-with-hardware-specs/66656 "2016-11-20T18:33:09Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![espogian](https://avatars.discourse-cdn.com/v4/letter/e/4491bb/32.png) [@espogian](https://discuss.elastic.co/u/espogian)\ **Post date:** [November 20, 2016, 6:33pm UTC](https://discuss.elastic.co/t/understanding-elasticsearch-performance-and-correlation-with-hardware-specs/66656/1 "2016-11-20T18:33:09Z")
Hello, Recently I'm doing a lot of tests on a machine with very limited hardware, in particular only 4 GB of RAM. Running Elasticsearch plus Kibana and a couple of Logstash instances, I'm noticing a lot of situations in which Kibana shows me the Elasticsearch timeout (\>30000ms). I think this is a valuable situation to practice with ELK requirements. However, I'm unaware of what are the reasons why Kibana is so slow. First thing first, Elasticsearch and Kibana are not showing particular errors. Logstash instances are sending data regularly. Nevertheless, working on Kibana is so slow and I can't understand why. Probably it is not a surprise, the Discover panel is the slowest page. On our production server the machine has 16 GB of RAM, and I think this helps much. But... How to understand when Elasticsearch is being "pushed to the limit"? 🙂 I found some very nice documentation (like [https://www.elastic.co/blog/found-sizing-elasticsearch](https://www.elastic.co/blog/found-sizing-elasticsearch)) but I think it would be valuable to discuss and summarize where one shoud look to assess if the performances of Elasticsearch are fine for the hardware specs on which it is running. Thanks 🙂 ---
**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\ **Post date:** [November 20, 2016, 6:56pm UTC](https://discuss.elastic.co/t/understanding-elasticsearch-performance-and-correlation-with-hardware-specs/66656/2 "2016-11-20T18:56:11Z")
It'd be worth looking at the hot threads output and seeing if you had any GCs during the timeouts. Also check for swapping. And iostat. ---
**Author:** ![espogian](https://avatars.discourse-cdn.com/v4/letter/e/4491bb/32.png) [@espogian](https://discuss.elastic.co/u/espogian)\ **Post date:** [November 20, 2016, 7:46pm UTC](https://discuss.elastic.co/t/understanding-elasticsearch-performance-and-correlation-with-hardware-specs/66656/3 "2016-11-20T19:46:49Z")
Hi, at the bottom of this message the (partial, due to character limits on this forum) hot threads output (`_nodes/hot_threads`) during a long search (without timeout, though). Frankly, I can't read information in there 😑 If you could give me some advice on what I should look for Swapping. AFAIK my swap partition has never been used. RAM consumption by Elasticsearch is about 60% of the total RAM available. Iostat: ``` Linux 4.4.0-47-generic (ubuntu) 11/20/2016 _x86_64_ (2 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 54.97 0.10 7.17 1.53 0.00 36.23 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 186.95 1686.27 1037.66 992321 610632 ``` BTW, I'm starting Elasticsearch with ES\_JAVA\_OPTS="-Xms2g -Xmx2g" heap size setting, basing these parameters on the instructions written here: [https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html](https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html) Thanks for the reply!!! 😃 `_nodes/hot_threads` during a Kibana Discovery: ``` ::: {ducktales-1}{eSpw3bV4RKmtCRwny35ffA}{9-onfn9sSGWbW9YSzAzXrA}{172.18.0.2}{172.18.0.2:9300} Hot threads at 2016-11-20T19:40:21.347Z, interval=500ms, busiestThreads=3, ignoreIdleThreads=true: 38.6% (193.1ms out of 500ms) cpu usage by thread 'elasticsearch[ducktales-1][search][T#1]' 2/10 snapshots sharing following 33 elements org.apache.lucene.util.IntBlockPool.nextBuffer(IntBlockPool.java:155) org.apache.lucene.util.IntBlockPool.newSlice(IntBlockPool.java:168) org.apache.lucene.util.IntBlockPool.access$200(IntBlockPool.java:26) org.apache.lucene.util.IntBlockPool$SliceWriter.startNewSlice(IntBlockPool.java:274) org.apache.lucene.index.memory.MemoryIndex.storeTerms(MemoryIndex.java:623) org.apache.lucene.index.memory.MemoryIndex.addField(MemoryIndex.java:526) org.apache.lucene.index.memory.MemoryIndex.addField(MemoryIndex.java:496) org.apache.lucene.index.memory.MemoryIndex.addField(MemoryIndex.java:472) org.apache.lucene.index.memory.MemoryIndex.addField(MemoryIndex.java:447) org.apache.lucene.index.memory.MemoryIndex.addField(MemoryIndex.java:364) [...] ``` ---
**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\ **Post date:** [November 21, 2016, 11:45pm UTC](https://discuss.elastic.co/t/understanding-elasticsearch-performance-and-correlation-with-hardware-specs/66656/4 "2016-11-21T23:45:12Z")
You can get around the character limits by linking to a [gist](https://gist.github.com/). Though it is cut off, I wonder if the MemoryIndex there is from highlighting. I've seen that come up before. In that case a multi-term query like `a*` or `aaaa~` can cause trouble. the `-Xms`/`-Xmx` is fine. No swapping is good. Looks like something nasty is eating the CPU like the highlighting I was guessing. Can you post a gist of the whole hot\_threads? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 19, 2016, 11:45pm UTC](https://discuss.elastic.co/t/understanding-elasticsearch-performance-and-correlation-with-hardware-specs/66656/5 "2016-12-19T23:45:31Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.