# Garbage Collection and Intermittant Search Performance issues **URL:** \ **Category:** Elasticsearch\ **Created:** [June 17, 2011, 8:43am UTC](https://discuss.elastic.co/t/garbage-collection-and-intermittant-search-performance-issues/4647 "2011-06-17T08:43:08Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![davrob](https://avatars.discourse-cdn.com/v4/letter/d/d78d45/32.png) [@davrob](https://discuss.elastic.co/u/davrob)\ **Post date:** [June 17, 2011, 8:43am UTC](https://discuss.elastic.co/t/garbage-collection-and-intermittant-search-performance-issues/4647/1 "2011-06-17T08:43:08Z")
Hi, Yesterday my users were reporting intermittant poor response times for searches, at the same time garbage collection seems to be running more often than usual in the index ([https://gist.github.com/1031079](https://gist.github.com/1031079)). JVM params in elasticsearch.in.sh are ES\_MAX\_MEM=2g. My first instinct was to increase the memory to 4g, any other tips on what I should be doing to prevent this? Best Regards, David. ---
**Author:** ![Enrique\_Medina\_Monte](https://avatars.discourse-cdn.com/v4/letter/e/4491bb/32.png) [@Enrique\_Medina\_Monte](https://discuss.elastic.co/u/Enrique_Medina_Monte)\ **Post date:** [June 17, 2011, 8:45am UTC](https://discuss.elastic.co/t/garbage-collection-and-intermittant-search-performance-issues/4647/2 "2011-06-17T08:45:04Z")
Use mlockall in your configuration to see whether it helps: > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. (see Memory Settings section) On Fri, Jun 17, 2011 at 10:43 AM, davrob2 [daviroberts@gmail.com](mailto:daviroberts@gmail.com) wrote: > Hi, > > Yesterday my users were reporting intermittant poor response times for > searches, at the same time garbage collection seems to be running more > often than usual in the index ([1031079’s gists · GitHub](https://gist.github.com/1031079)). > > JVM params in elasticsearch.in.sh are ES\_MAX\_MEM=2g. > > My first instinct was to increase the memory to 4g, any other tips on > what I should be doing to prevent this? > > Best Regards, > > David. ---
**Author:** ![davrob](https://avatars.discourse-cdn.com/v4/letter/d/d78d45/32.png) [@davrob](https://discuss.elastic.co/u/davrob)\ **Post date:** [June 17, 2011, 2:53pm UTC](https://discuss.elastic.co/t/garbage-collection-and-intermittant-search-performance-issues/4647/3 "2011-06-17T14:53:03Z")
mlocakall seems quite dangerous: ``` Note, this is experimental feature, and might cause the JVM or ``` shell session to exit if failing to allocate the memory (because not enough memory is available on the machine). Can you tell me any more about what it does and how it works? On Jun 17, 9:45 am, Enrique Medina Montenegro [e.medin...@gmail.com](mailto:e.medin...@gmail.com) wrote: > Use mlockall in your configuration to see whether it helps: > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/setup/installation.html) > > (see Memory Settings section) > > On Fri, Jun 17, 2011 at 10:43 AM, davrob2 [davirobe...@gmail.com](mailto:davirobe...@gmail.com) wrote: > > > Hi, > > > Yesterday my users were reporting intermittant poor response times for > > searches, at the same time garbage collection seems to be running more > > often than usual in the index ([1031079’s gists · GitHub](https://gist.github.com/1031079)). > > > JVM params in elasticsearch.in.sh are ES\_MAX\_MEM=2g. > > > My first instinct was to increase the memory to 4g, any other tips on > > what I should be doing to prevent this? > > > Best Regards, > > > David. ---
**Author:** ![colinsurprenant](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/colinsurprenant/32/14776_2.png) [@colinsurprenant](https://discuss.elastic.co/u/colinsurprenant)\ **Post date:** [June 17, 2011, 3:07pm UTC](https://discuss.elastic.co/t/garbage-collection-and-intermittant-search-performance-issues/4647/4 "2011-06-17T15:07:37Z")
afaik this should only happen at startup when ES tries to allocate its memory no? On Fri, Jun 17, 2011 at 10:53 AM, davrob2 [daviroberts@gmail.com](mailto:daviroberts@gmail.com) wrote: > mlocakall seems quite dangerous: > > ``` > Note, this is experimental feature, and might cause the JVM or > > ``` > > shell session to exit if failing to allocate the memory (because not > enough memory is available on the machine). > > Can you tell me any more about what it does and how it works? > > On Jun 17, 9:45 am, Enrique Medina Montenegro [e.medin...@gmail.com](mailto:e.medin...@gmail.com) > wrote: > > > Use mlockall in your configuration to see whether it helps: > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/setup/installation.html) > > > > (see Memory Settings section) > > > > On Fri, Jun 17, 2011 at 10:43 AM, davrob2 [davirobe...@gmail.com](mailto:davirobe...@gmail.com) wrote: > > > > > Hi, > > > > > Yesterday my users were reporting intermittant poor response times for > > > searches, at the same time garbage collection seems to be running more > > > often than usual in the index ([1031079’s gists · GitHub](https://gist.github.com/1031079)). > > > > > JVM params in elasticsearch.in.sh are ES\_MAX\_MEM=2g. > > > > > My first instinct was to increase the memory to 4g, any other tips on > > > what I should be doing to prevent this? > > > > > Best Regards, > > > > > David. ---
**Author:** ![David\_Williams](https://avatars.discourse-cdn.com/v4/letter/d/90ced4/32.png) [@David\_Williams](https://discuss.elastic.co/u/David_Williams)\ **Post date:** [June 17, 2011, 4:55pm UTC](https://discuss.elastic.co/t/garbage-collection-and-intermittant-search-performance-issues/4647/5 "2011-06-17T16:55:07Z")
when using mlockall, you should also used a fixed size heap (min and max are equal) so it either allocates all of it, or won't start. An alternative is to just run without swap. On a dedicated elastic search server anything that gets moved to swap is a bad thing. On Fri, Jun 17, 2011 at 8:07 AM, Colin Surprenant [colin.surprenant@gmail.com](mailto:colin.surprenant@gmail.com) wrote: > afaik this should only happen at startup when ES tries to allocate its > memory no? > > On Fri, Jun 17, 2011 at 10:53 AM, davrob2 [daviroberts@gmail.com](mailto:daviroberts@gmail.com) wrote: > > > mlocakall seems quite dangerous: > > > > ``` > > Note, this is experimental feature, and might cause the JVM or > > > > ``` > > > > shell session to exit if failing to allocate the memory (because not > > enough memory is available on the machine). > > > > Can you tell me any more about what it does and how it works? > > > > On Jun 17, 9:45 am, Enrique Medina Montenegro [e.medin...@gmail.com](mailto:e.medin...@gmail.com) > > wrote: > > > > > Use mlockall in your configuration to see whether it helps: > > > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/setup/installation.html) > > > > > > (see Memory Settings section) > > > > > > On Fri, Jun 17, 2011 at 10:43 AM, davrob2 [davirobe...@gmail.com](mailto:davirobe...@gmail.com) wrote: > > > > > > > Hi, > > > > > > > Yesterday my users were reporting intermittant poor response times for > > > > searches, at the same time garbage collection seems to be running more > > > > often than usual in the index ([1031079’s gists · GitHub](https://gist.github.com/1031079)). > > > > > > > JVM params in elasticsearch.in.sh are ES\_MAX\_MEM=2g. > > > > > > > My first instinct was to increase the memory to 4g, any other tips on > > > > what I should be doing to prevent this? > > > > > > > Best Regards, > > > > > > > David. ---
**Author:** ![davrob](https://avatars.discourse-cdn.com/v4/letter/d/d78d45/32.png) [@davrob](https://discuss.elastic.co/u/davrob)\ **Post date:** [June 18, 2011, 3:06pm UTC](https://discuss.elastic.co/t/garbage-collection-and-intermittant-search-performance-issues/4647/6 "2011-06-18T15:06:12Z")
Actually, I did miss this big post on dealing with these issues: [http://elasticsearch-users.115913.n3.nabble.com/0-16-Release-Plan-td2831600.html#a2833637](http://elasticsearch-users.115913.n3.nabble.com/0-16-Release-Plan-td2831600.html#a2833637) So I will take this approach and see what happens, including the mlockall option. Thanks for all your suggestions. David. On Jun 17, 5:55 pm, David Williams [williams.da...@gmail.com](mailto:williams.da...@gmail.com) wrote: > when using mlockall, you should also used a fixed size heap (min and > max are equal) so it either allocates all of it, or won't start. > > An alternative is to just run without swap. On a dedicated elastic > search server anything that gets moved to swap is a bad thing. > > On Fri, Jun 17, 2011 at 8:07 AM, Colin Surprenant > > [colin.surpren...@gmail.com](mailto:colin.surpren...@gmail.com) wrote: > > > afaik this should only happen at startup when ES tries to allocate its > > memory no? > > > On Fri, Jun 17, 2011 at 10:53 AM, davrob2 [davirobe...@gmail.com](mailto:davirobe...@gmail.com) wrote: > > > > > mlocakall seems quite dangerous: > > > > ``` > > > Note, this is experimental feature, and might cause the JVM or > > > > > > ``` > > > > > > shell session to exit if failing to allocate the memory (because not > > > enough memory is available on the machine). > > > > Can you tell me any more about what it does and how it works? > > > > On Jun 17, 9:45 am, Enrique Medina Montenegro [e.medin...@gmail.com](mailto:e.medin...@gmail.com) > > > wrote: > > > > > > > Use mlockall in your configuration to see whether it helps: > > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/setup/installation.html) > > > > > (see Memory Settings section) > > > > > On Fri, Jun 17, 2011 at 10:43 AM, davrob2 [davirobe...@gmail.com](mailto:davirobe...@gmail.com) wrote: > > > > > > > > > Hi, > > > > > > Yesterday my users were reporting intermittant poor response times for > > > > > searches, at the same time garbage collection seems to be running more > > > > > often than usual in the index ([1031079’s gists · GitHub](https://gist.github.com/1031079)). > > > > > > JVM params in elasticsearch.in.sh are ES\_MAX\_MEM=2g. > > > > > > My first instinct was to increase the memory to 4g, any other tips on > > > > > what I should be doing to prevent this? > > > > > > Best Regards, > > > > > > David. ---
**Author:** ![davrob](https://avatars.discourse-cdn.com/v4/letter/d/d78d45/32.png) [@davrob](https://discuss.elastic.co/u/davrob)\ **Post date:** [June 21, 2011, 8:45am UTC](https://discuss.elastic.co/t/garbage-collection-and-intermittant-search-performance-issues/4647/7 "2011-06-21T08:45:34Z")
Regarding the memory settings here: [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/setup/installation.html) Can anyone recommend the equivalent of ulimit -l for Solaris? Is it necessary / possible to apply this setting to lock the memory in Solaris? When I execute the ulimit command it returns "unlimited", but I'm not sure if that has anything to do with the "max locked memory" setting. On Jun 18, 4:06 pm, davrob2 [davirobe...@gmail.com](mailto:davirobe...@gmail.com) wrote: > Actually, I did miss this big post on dealing with these issues: > > [http://elasticsearch-users.115913.n3.nabble.com/0-16-Release-Plan-td2](http://elasticsearch-users.115913.n3.nabble.com/0-16-Release-Plan-td2)... > > So I will take this approach and see what happens, including the > mlockall option. > > Thanks for all your suggestions. > > David. > > On Jun 17, 5:55 pm, David Williams [williams.da...@gmail.com](mailto:williams.da...@gmail.com) wrote: > > > when using mlockall, you should also used a fixed size heap (min and > > max are equal) so it either allocates all of it, or won't start. > > > An alternative is to just run without swap. On a dedicated elastic > > search server anything that gets moved to swap is a bad thing. > > > On Fri, Jun 17, 2011 at 8:07 AM, Colin Surprenant > > > [colin.surpren...@gmail.com](mailto:colin.surpren...@gmail.com) wrote: > > > > > afaik this should only happen at startup when ES tries to allocate its > > > memory no? > > > > On Fri, Jun 17, 2011 at 10:53 AM, davrob2 [davirobe...@gmail.com](mailto:davirobe...@gmail.com) wrote: > > > > > > > mlocakall seems quite dangerous: > > > > > ``` > > > > Note, this is experimental feature, and might cause the JVM or > > > > > > > > ``` > > > > > > > > shell session to exit if failing to allocate the memory (because not > > > > enough memory is available on the machine). > > > > > Can you tell me any more about what it does and how it works? > > > > > On Jun 17, 9:45 am, Enrique Medina Montenegro [e.medin...@gmail.com](mailto:e.medin...@gmail.com) > > > > wrote: > > > > > > > > > Use mlockall in your configuration to see whether it helps: > > > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/setup/installation.html) > > > > > > (see Memory Settings section) > > > > > > On Fri, Jun 17, 2011 at 10:43 AM, davrob2 [davirobe...@gmail.com](mailto:davirobe...@gmail.com) wrote: > > > > > > > > > > > Hi, > > > > > > > Yesterday my users were reporting intermittant poor response times for > > > > > > searches, at the same time garbage collection seems to be running more > > > > > > often than usual in the index ([1031079’s gists · GitHub](https://gist.github.com/1031079)). > > > > > > > JVM params in elasticsearch.in.sh are ES\_MAX\_MEM=2g. > > > > > > > My first instinct was to increase the memory to 4g, any other tips on > > > > > > what I should be doing to prevent this? > > > > > > > Best Regards, > > > > > > > David. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:03am UTC](https://discuss.elastic.co/t/garbage-collection-and-intermittant-search-performance-issues/4647/8 "2017-07-06T04:03:01Z")