# Terrible low performance search despite enough resources **URL:** \ **Category:** Elasticsearch\ **Created:** [January 11, 2022, 8:44am UTC](https://discuss.elastic.co/t/terrible-low-performance-search-despite-enough-resources/293992 "2022-01-11T08:44:38Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![zarmci](https://avatars.discourse-cdn.com/v4/letter/z/a587f6/32.png) [@zarmci](https://discuss.elastic.co/u/zarmci)\ **Post date:** [January 11, 2022, 8:44am UTC](https://discuss.elastic.co/t/terrible-low-performance-search-despite-enough-resources/293992/1 "2022-01-11T08:44:38Z")
We have two 3-nodes Elasticsearch cluster. Despite these clusters have approximately similar resources and the indices are quite similar, the speed of search in one of them is **tenfold** slower than another. We spent a lot of time for troubleshooting but couldn't find what is the problem. The odd thing is that the faster cluster is in production and is under more load than the slower one that is in stage zone! Since the faster cluster has more load we suspected to `cache`, but it doesn't seem to be the problem after doing some tests to check its effect. I checked the storage type of two clusters to ensure the faster one has not `ssd` and have seen that's not the case. I've also checked `GET _nodes/os` and `GET _nodes/jvm`. All things except for `name`s, `ip`s and small differences in resources are equal, only the `using_compressed_ordinary_object_pointers` property in faster cluster is `false` but in the slower is `true`. I couldn't find good enough documents about this property and its effect on search performance and am curious to know : if this property can cause the problem? is it safe to change it in slower cluster whiteout any side effect? if this is safe, how can I change it? and if this property is not the reason, what another thing is potential enough to be the reason of such a terrible low performance search? ---
**Author:** ![FALEN](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/falen/32/82754_2.png) [@FALEN](https://discuss.elastic.co/u/FALEN)\ **Post date:** [January 11, 2022, 1:00pm UTC](https://discuss.elastic.co/t/terrible-low-performance-search-despite-enough-resources/293992/2 "2022-01-11T13:00:23Z")
Did you checked your jvm.options for -xms/-xmx? Are they configured to be %50 of your total memory? What is your Ram/CPU/Disk details. How many shards do you have per node? Can you also check ram/cpu usage of java service in each node? ---
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [January 11, 2022, 1:30pm UTC](https://discuss.elastic.co/t/terrible-low-performance-search-despite-enough-resources/293992/3 "2022-01-11T13:30:56Z")
You need to share the specs of your cluster, how many CPUs, Memory and Disk each node has, what is the Java HEAP configuration, what is the type of the Disk. Also, share the number of indices and shards in both cluster as well as the versions. The compressed ordinary object pointers will depend on the Java Heap Size, it is explained in [this part of the documentation](https://www.elastic.co/guide/en/elasticsearch/reference/7.16/advanced-configuration.html#set-jvm-heap-size) and it should be _true_. ---
**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:** [January 13, 2022, 5:48am UTC](https://discuss.elastic.co/t/terrible-low-performance-search-despite-enough-resources/293992/4 "2022-01-13T05:48:18Z")
What is the output from the `_cluster/stats?pretty&human` API? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [February 10, 2022, 5:49am UTC](https://discuss.elastic.co/t/terrible-low-performance-search-despite-enough-resources/293992/5 "2022-02-10T05:49:08Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.