.
> > > To view this discussion on the web visit
> > > [https://groups.google.com/d/msgid/elasticsearch/5629c17d-603e-4a3c-981c-4bb6c0f3847e%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/5629c17d-603e-4a3c-981c-4bb6c0f3847e%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/5629c17d-603e-4a3c-981c-4bb6c0f3847e%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/5629c17d-603e-4a3c-981c-4bb6c0f3847e%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > .
> > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/c78b9c70-db54-441d-a408-1c7c6f4b6b65%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c78b9c70-db54-441d-a408-1c7c6f4b6b65%40googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)
#### Post date: [March 5, 2014, 11:36am UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/6 "2014-03-05T11:36:23Z")
Look at the output from the hot threads API to see what is consuming the
CPU. Also, I'd check your garbage collection times (look in the logs and
in the nodes stats output), and make sure that you have zero bytes in swap.
On 5 March 2014 11:20, Aivars Irmejs [aivars@gmail.com](mailto:aivars@gmail.com) wrote:
> Recently I've seen posts saying that latest version of OpenJDK is fine.
> I'd rather find a reliable way to debug the issue than start changing
> random things.
>
> Thanks,
> Aivars
>
> On Wednesday, March 5, 2014 11:57:30 AM UTC+2, Mark Walkom wrote:
>
> > It's standard/best practise to use Oracle's java for performance and
> > stability.
> > There's a number of old list posts around this that would be worth
> > looking into.
> >
> > Regards,
> > Mark Walkom
> >
> > Infrastructure Engineer
> > Campaign Monitor
> > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com)
> > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> >
> > On 5 March 2014 20:34, Aivars Irmejs [aiv...@gmail.com](mailto:aiv...@gmail.com) wrote:
> >
> > > Changing Java would not be trivial. Knowing that ES gets tested against
> > > OpenJDK during development, could Oracle Java really help, or is this just
> > > a standard answer to all kinds of issues? If there's a big chance that it
> > > will help I will do it. Even better if there are some kind of diagnostics
> > > that could tell me that OpenJDK is at fault.
> > >
> > > Thanks,
> > > Aivars
> > >
> > > On Wednesday, March 5, 2014 10:59:01 AM UTC+2, Mark Walkom wrote:
> > >
> > > > Use Oracle java, not OpenJDK that might help.
> > > >
> > > > Also check what happens with GC, using something like the Marvel or
> > > > ElasticHQ plugins will give you insight into that.
> > > >
> > > > Regards,
> > > > Mark Walkom
> > > >
> > > > Infrastructure Engineer
> > > > Campaign Monitor
> > > > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com)
> > > > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> > > >
> > > > On 5 March 2014 19:48, Aivars Irmejs [aiv...@gmail.com](mailto:aiv...@gmail.com) wrote:
> > > >
> > > > > When I'm starting or restarting ES service, its CPU use hovers at 3%
> > > > > CPU which is great. After some time and some use the CPU use will climb to
> > > > > 30%-100% and stay about that level even when idle. The first time it
> > > > > happens flushing helps - after the flush CPU level returns to the nice and
> > > > > pleasant 3% but eventually even that stops helping and only the service
> > > > > restart does the trick.
> > > > >
> > > > > 30%-100% CPU use could be tolerated theoretically since the server has
> > > > > multiple CPUs, but it's a VPS and I don't want to use more resources than I
> > > > > need. ES works perfectly with 3% CPU use before it starts misbehaving.
> > > > >
> > > > > What I want to figure most of all is why that happens and ideally make
> > > > > it stay at the 3% level all the time, but I'm not sure how to go about
> > > > > debugging it.
> > > > >
> > > > > Hot threads: [hot threads · GitHub](https://gist.github.com/kaitnieks/9363338)
> > > > > OpenJDK 1.7.0\_51
> > > > > 1 node, 300 indices
> > > > > multicast disabled
> > > > > happens with and without network.tcp.blocking, but when
> > > > > network.tcp.blocking is false, CPU use seems to be a little higher.
> > > > >
> > > > > Thanks,
> > > > > Aivars
> > > > >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "elasticsearch" group.
> > > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > > msgid/elasticsearch/0566e0b0-16cc-4f16-a297-2e187b0cbdcc%40goo
> > > > > [glegroups.com](http://glegroups.com)[https://groups.google.com/d/msgid/elasticsearch/0566e0b0-16cc-4f16-a297-2e187b0cbdcc%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/0566e0b0-16cc-4f16-a297-2e187b0cbdcc%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > > .
> > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "elasticsearch" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > msgid/elasticsearch/5629c17d-603e-4a3c-981c-4bb6c0f3847e%
> > > > [40googlegroups.com](http://40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/5629c17d-603e-4a3c-981c-4bb6c0f3847e%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/5629c17d-603e-4a3c-981c-4bb6c0f3847e%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > .
> > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> > To view this discussion on the web visit
> > [https://groups.google.com/d/msgid/elasticsearch/c78b9c70-db54-441d-a408-1c7c6f4b6b65%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c78b9c70-db54-441d-a408-1c7c6f4b6b65%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/c78b9c70-db54-441d-a408-1c7c6f4b6b65%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/c78b9c70-db54-441d-a408-1c7c6f4b6b65%40googlegroups.com?utm_medium=email&utm_source=footer)
> > .
>
> For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAPt3XKSk0PzJYo4JPR5fQUSjkL0%2BtvPAnxk5tz\_xcfXRMBbqng%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAPt3XKSk0PzJYo4JPR5fQUSjkL0%2BtvPAnxk5tz_xcfXRMBbqng%40mail.gmail.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@jprante](https://discuss.elastic.co/u/jprante)
#### Post date: [March 5, 2014, 1:00pm UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/7 "2014-03-05T13:00:11Z")
You say "after some use", can you tell us about the garbage collection?
What heap memory do you use?
Jörg
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHgVU41MYT6mkQdAUke7XimGozoTJshQhZs0KSycmezyA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHgVU41MYT6mkQdAUke7XimGozoTJshQhZs0KSycmezyA%40mail.gmail.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Aivars\_Irmejs](https://discuss.elastic.co/u/Aivars_Irmejs)
#### Post date: [March 6, 2014, 9:00am UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/8 "2014-03-06T09:00:30Z")
I'll start with the fact that I tried Oracle Java and that didn't help.
I did some graphing and here is some more information via bigdesk - the
good, fresh state:
[http://kaitnieks.com/images/elasticsearch\_good.png](http://kaitnieks.com/images/elasticsearch_good.png)
The worsened state:
[http://kaitnieks.com/images/elasticsearch\_less\_good.png](http://kaitnieks.com/images/elasticsearch_less_good.png)
The images indeed show that GC is more active and the fight against heap
memory limit occurs more often.
The question is - why does it happen, knowing that Elasticsearch idles in
both cases (in 2nd image it has finished its indexings and waiting for the
next) and how to return to the good, clean state without restarting? Are
there any commands to get rid of any caches etc (which I don't need) that
might help?
Thanks,
Aivars
On Wednesday, March 5, 2014 10:48:47 AM UTC+2, Aivars Irmejs wrote:
> When I'm starting or restarting ES service, its CPU use hovers at 3% CPU
> which is great. After some time and some use the CPU use will climb to
> 30%-100% and stay about that level even when idle. The first time it
> happens flushing helps - after the flush CPU level returns to the nice and
> pleasant 3% but eventually even that stops helping and only the service
> restart does the trick.
>
> 30%-100% CPU use could be tolerated theoretically since the server has
> multiple CPUs, but it's a VPS and I don't want to use more resources than I
> need. ES works perfectly with 3% CPU use before it starts misbehaving.
>
> What I want to figure most of all is why that happens and ideally make it
> stay at the 3% level all the time, but I'm not sure how to go about
> debugging it.
>
> Hot threads: [hot threads · GitHub](https://gist.github.com/kaitnieks/9363338)
> OpenJDK 1.7.0\_51
> 1 node, 300 indices
> multicast disabled
> happens with and without network.tcp.blocking, but when
> network.tcp.blocking is false, CPU use seems to be a little higher.
>
> Thanks,
> Aivars
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [March 6, 2014, 9:13am UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/9 "2014-03-06T09:13:39Z")
Can you provide node stats, RAM, heap size, document count, index size etc?
Regards,
Mark Walkom
Infrastructure Engineer
Campaign Monitor
email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)
web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
On 6 March 2014 20:00, Aivars Irmejs [aivars@gmail.com](mailto:aivars@gmail.com) wrote:
> I'll start with the fact that I tried Oracle Java and that didn't help.
>
> I did some graphing and here is some more information via bigdesk - the
> good, fresh state:
> [http://kaitnieks.com/images/elasticsearch\_good.png](http://kaitnieks.com/images/elasticsearch_good.png)
> The worsened state:
> [http://kaitnieks.com/images/elasticsearch\_less\_good.png](http://kaitnieks.com/images/elasticsearch_less_good.png)
> The images indeed show that GC is more active and the fight against heap
> memory limit occurs more often.
>
> The question is - why does it happen, knowing that Elasticsearch idles in
> both cases (in 2nd image it has finished its indexings and waiting for the
> next) and how to return to the good, clean state without restarting? Are
> there any commands to get rid of any caches etc (which I don't need) that
> might help?
>
> Thanks,
> Aivars
>
> On Wednesday, March 5, 2014 10:48:47 AM UTC+2, Aivars Irmejs wrote:
>
> > When I'm starting or restarting ES service, its CPU use hovers at 3% CPU
> > which is great. After some time and some use the CPU use will climb to
> > 30%-100% and stay about that level even when idle. The first time it
> > happens flushing helps - after the flush CPU level returns to the nice and
> > pleasant 3% but eventually even that stops helping and only the service
> > restart does the trick.
> >
> > 30%-100% CPU use could be tolerated theoretically since the server has
> > multiple CPUs, but it's a VPS and I don't want to use more resources than I
> > need. ES works perfectly with 3% CPU use before it starts misbehaving.
> >
> > What I want to figure most of all is why that happens and ideally make it
> > stay at the 3% level all the time, but I'm not sure how to go about
> > debugging it.
> >
> > Hot threads: [hot threads · GitHub](https://gist.github.com/kaitnieks/9363338)
> > OpenJDK 1.7.0\_51
> > 1 node, 300 indices
> > multicast disabled
> > happens with and without network.tcp.blocking, but when
> > network.tcp.blocking is false, CPU use seems to be a little higher.
> >
> > Thanks,
> > Aivars
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> To view this discussion on the web visit
> [https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm_medium=email&utm_source=footer)
> .
> For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEM624awh\_phk3NBm1h%2BUxaS86UQ21zhNTfW\_yxYy\_%2BqCrNjPg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624awh_phk3NBm1h%2BUxaS86UQ21zhNTfW_yxYy_%2BqCrNjPg%40mail.gmail.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Aivars\_Irmejs](https://discuss.elastic.co/u/Aivars_Irmejs)
#### Post date: [March 6, 2014, 9:27am UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/10 "2014-03-06T09:27:11Z")
RAM: 1.5 GB
Heap: 700 Mb
Index count: 303
Document count ([http://h3.blumentals.net:9200/\_count](http://h3.blumentals.net:9200/_count) - like so?): 2400432 -
which seems more than expected...
Thanks,
Aivars
On Thursday, March 6, 2014 11:13:39 AM UTC+2, Mark Walkom wrote:
> Can you provide node stats, RAM, heap size, document count, index size etc?
>
> Regards,
> Mark Walkom
>
> Infrastructure Engineer
> Campaign Monitor
> email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com) \
> web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
>
> On 6 March 2014 20:00, Aivars Irmejs \<[aiv...@gmail.com](mailto:aiv...@gmail.com) \\>wrote:
>
> > I'll start with the fact that I tried Oracle Java and that didn't help.
> >
> > I did some graphing and here is some more information via bigdesk - the
> > good, fresh state:
> > [http://kaitnieks.com/images/elasticsearch\_good.png](http://kaitnieks.com/images/elasticsearch_good.png)
> > The worsened state:
> > [http://kaitnieks.com/images/elasticsearch\_less\_good.png](http://kaitnieks.com/images/elasticsearch_less_good.png)
> > The images indeed show that GC is more active and the fight against heap
> > memory limit occurs more often.
> >
> > The question is - why does it happen, knowing that Elasticsearch idles in
> > both cases (in 2nd image it has finished its indexings and waiting for the
> > next) and how to return to the good, clean state without restarting? Are
> > there any commands to get rid of any caches etc (which I don't need) that
> > might help?
> >
> > Thanks,
> > Aivars
> >
> > On Wednesday, March 5, 2014 10:48:47 AM UTC+2, Aivars Irmejs wrote:
> >
> > > When I'm starting or restarting ES service, its CPU use hovers at 3% CPU
> > > which is great. After some time and some use the CPU use will climb to
> > > 30%-100% and stay about that level even when idle. The first time it
> > > happens flushing helps - after the flush CPU level returns to the nice and
> > > pleasant 3% but eventually even that stops helping and only the service
> > > restart does the trick.
> > >
> > > 30%-100% CPU use could be tolerated theoretically since the server has
> > > multiple CPUs, but it's a VPS and I don't want to use more resources than I
> > > need. ES works perfectly with 3% CPU use before it starts misbehaving.
> > >
> > > What I want to figure most of all is why that happens and ideally make
> > > it stay at the 3% level all the time, but I'm not sure how to go about
> > > debugging it.
> > >
> > > Hot threads: [hot threads · GitHub](https://gist.github.com/kaitnieks/9363338)
> > > OpenJDK 1.7.0\_51
> > > 1 node, 300 indices
> > > multicast disabled
> > > happens with and without network.tcp.blocking, but when
> > > network.tcp.blocking is false, CPU use seems to be a little higher.
> > >
> > > Thanks,
> > > Aivars
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \.
> > To view this discussion on the web visit
> > [https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm_medium=email&utm_source=footer)
> > .
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [March 6, 2014, 9:30am UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/11 "2014-03-06T09:30:50Z")
700MB heap is really, really small.
It looks like you're hitting the limits of your node, you either need to
remove some documents or add more nodes.
Regards,
Mark Walkom
Infrastructure Engineer
Campaign Monitor
email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)
web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
On 6 March 2014 20:27, Aivars Irmejs [aivars@gmail.com](mailto:aivars@gmail.com) wrote:
> RAM: 1.5 GB
> Heap: 700 Mb
> Index count: 303
> Document count ([http://h3.blumentals.net:9200/\_count](http://h3.blumentals.net:9200/_count) - like so?): 2400432
>
> - which seems more than expected...
>
> Thanks,
> Aivars
>
> On Thursday, March 6, 2014 11:13:39 AM UTC+2, Mark Walkom wrote:
>
> > Can you provide node stats, RAM, heap size, document count, index size
> > etc?
> >
> > Regards,
> > Mark Walkom
> >
> > Infrastructure Engineer
> > Campaign Monitor
> > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com)
> > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> >
> > On 6 March 2014 20:00, Aivars Irmejs [aiv...@gmail.com](mailto:aiv...@gmail.com) wrote:
> >
> > > I'll start with the fact that I tried Oracle Java and that didn't help.
> > >
> > > I did some graphing and here is some more information via bigdesk - the
> > > good, fresh state:
> > > [http://kaitnieks.com/images/elasticsearch\_good.png](http://kaitnieks.com/images/elasticsearch_good.png)
> > > The worsened state:
> > > [http://kaitnieks.com/images/elasticsearch\_less\_good.png](http://kaitnieks.com/images/elasticsearch_less_good.png)
> > > The images indeed show that GC is more active and the fight against heap
> > > memory limit occurs more often.
> > >
> > > The question is - why does it happen, knowing that Elasticsearch idles
> > > in both cases (in 2nd image it has finished its indexings and waiting for
> > > the next) and how to return to the good, clean state without restarting?
> > > Are there any commands to get rid of any caches etc (which I don't need)
> > > that might help?
> > >
> > > Thanks,
> > > Aivars
> > >
> > > On Wednesday, March 5, 2014 10:48:47 AM UTC+2, Aivars Irmejs wrote:
> > >
> > > > When I'm starting or restarting ES service, its CPU use hovers at 3%
> > > > CPU which is great. After some time and some use the CPU use will climb to
> > > > 30%-100% and stay about that level even when idle. The first time it
> > > > happens flushing helps - after the flush CPU level returns to the nice and
> > > > pleasant 3% but eventually even that stops helping and only the service
> > > > restart does the trick.
> > > >
> > > > 30%-100% CPU use could be tolerated theoretically since the server has
> > > > multiple CPUs, but it's a VPS and I don't want to use more resources than I
> > > > need. ES works perfectly with 3% CPU use before it starts misbehaving.
> > > >
> > > > What I want to figure most of all is why that happens and ideally make
> > > > it stay at the 3% level all the time, but I'm not sure how to go about
> > > > debugging it.
> > > >
> > > > Hot threads: [hot threads · GitHub](https://gist.github.com/kaitnieks/9363338)
> > > > OpenJDK 1.7.0\_51
> > > > 1 node, 300 indices
> > > > multicast disabled
> > > > happens with and without network.tcp.blocking, but when
> > > > network.tcp.blocking is false, CPU use seems to be a little higher.
> > > >
> > > > Thanks,
> > > > Aivars
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "elasticsearch" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%
> > > [40googlegroups.com](http://40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > .
> > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> > To view this discussion on the web visit
> > [https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com?utm_medium=email&utm_source=footer)
> > .
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEM624agTuhrOgnteVQMXqysDE0e8w0NMjR8rUB6sYq01ihzHA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624agTuhrOgnteVQMXqysDE0e8w0NMjR8rUB6sYq01ihzHA%40mail.gmail.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Aivars\_Irmejs](https://discuss.elastic.co/u/Aivars_Irmejs)
#### Post date: [March 6, 2014, 10:08am UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/12 "2014-03-06T10:08:09Z")
I get it's not several GB like most of you use, but when I run ES and while
it's still fresh it works wonderfully - searches quickly and does not
consume CPU. All I want to do is to find a way to prevent it from going
stale, e.g. turn off something that makes the memory fill up unnecessarily
(for my use case), so that it remains in the fresh state where only small
amount of memory is consumed.
Thanks,
Aivars
On Thursday, March 6, 2014 11:30:50 AM UTC+2, Mark Walkom wrote:
> 700MB heap is really, really small.
> It looks like you're hitting the limits of your node, you either need to
> remove some documents or add more nodes.
>
> Regards,
> Mark Walkom
>
> Infrastructure Engineer
> Campaign Monitor
> email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com) \
> web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
>
> On 6 March 2014 20:27, Aivars Irmejs \<[aiv...@gmail.com](mailto:aiv...@gmail.com) \\>wrote:
>
> > RAM: 1.5 GB
> > Heap: 700 Mb
> > Index count: 303
> > Document count ([http://h3.blumentals.net:9200/\_count](http://h3.blumentals.net:9200/_count) - like so?):
> > 2400432 - which seems more than expected...
> >
> > Thanks,
> > Aivars
> >
> > On Thursday, March 6, 2014 11:13:39 AM UTC+2, Mark Walkom wrote:
> >
> > > Can you provide node stats, RAM, heap size, document count, index size
> > > etc?
> > >
> > > Regards,
> > > Mark Walkom
> > >
> > > Infrastructure Engineer
> > > Campaign Monitor
> > > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com)
> > > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> > >
> > > On 6 March 2014 20:00, Aivars Irmejs [aiv...@gmail.com](mailto:aiv...@gmail.com) wrote:
> > >
> > > > I'll start with the fact that I tried Oracle Java and that didn't help.
> > > >
> > > > I did some graphing and here is some more information via bigdesk - the
> > > > good, fresh state:
> > > > [http://kaitnieks.com/images/elasticsearch\_good.png](http://kaitnieks.com/images/elasticsearch_good.png)
> > > > The worsened state:
> > > > [http://kaitnieks.com/images/elasticsearch\_less\_good.png](http://kaitnieks.com/images/elasticsearch_less_good.png)
> > > > The images indeed show that GC is more active and the fight against
> > > > heap memory limit occurs more often.
> > > >
> > > > The question is - why does it happen, knowing that Elasticsearch idles
> > > > in both cases (in 2nd image it has finished its indexings and waiting for
> > > > the next) and how to return to the good, clean state without restarting?
> > > > Are there any commands to get rid of any caches etc (which I don't need)
> > > > that might help?
> > > >
> > > > Thanks,
> > > > Aivars
> > > >
> > > > On Wednesday, March 5, 2014 10:48:47 AM UTC+2, Aivars Irmejs wrote:
> > > >
> > > > > When I'm starting or restarting ES service, its CPU use hovers at 3%
> > > > > CPU which is great. After some time and some use the CPU use will climb to
> > > > > 30%-100% and stay about that level even when idle. The first time it
> > > > > happens flushing helps - after the flush CPU level returns to the nice and
> > > > > pleasant 3% but eventually even that stops helping and only the service
> > > > > restart does the trick.
> > > > >
> > > > > 30%-100% CPU use could be tolerated theoretically since the server has
> > > > > multiple CPUs, but it's a VPS and I don't want to use more resources than I
> > > > > need. ES works perfectly with 3% CPU use before it starts misbehaving.
> > > > >
> > > > > What I want to figure most of all is why that happens and ideally make
> > > > > it stay at the 3% level all the time, but I'm not sure how to go about
> > > > > debugging it.
> > > > >
> > > > > Hot threads: [hot threads · GitHub](https://gist.github.com/kaitnieks/9363338)
> > > > > OpenJDK 1.7.0\_51
> > > > > 1 node, 300 indices
> > > > > multicast disabled
> > > > > happens with and without network.tcp.blocking, but when
> > > > > network.tcp.blocking is false, CPU use seems to be a little higher.
> > > > >
> > > > > Thanks,
> > > > > Aivars
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "elasticsearch" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%
> > > > [40googlegroups.com](http://40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > .
> > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "elasticsearch" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \.
> > > To view this discussion on the web visit
> > > [https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > .
> > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/a65fa610-ecdc-47a5-9fd3-72ffb38318c6%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/a65fa610-ecdc-47a5-9fd3-72ffb38318c6%40googlegroups.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [March 6, 2014, 10:11am UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/13 "2014-03-06T10:11:10Z")
At this stage you're going to be wasting more time than it's worth to save
a few ten's of megabtyes (maybe).
Someone else might have some ideas though.
Regards,
Mark Walkom
Infrastructure Engineer
Campaign Monitor
email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com)
web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
On 6 March 2014 21:08, Aivars Irmejs [aivars@gmail.com](mailto:aivars@gmail.com) wrote:
> I get it's not several GB like most of you use, but when I run ES and
> while it's still fresh it works wonderfully - searches quickly and does not
> consume CPU. All I want to do is to find a way to prevent it from going
> stale, e.g. turn off something that makes the memory fill up unnecessarily
> (for my use case), so that it remains in the fresh state where only small
> amount of memory is consumed.
>
> Thanks,
> Aivars
>
> On Thursday, March 6, 2014 11:30:50 AM UTC+2, Mark Walkom wrote:
>
> > 700MB heap is really, really small.
> > It looks like you're hitting the limits of your node, you either need to
> > remove some documents or add more nodes.
> >
> > Regards,
> > Mark Walkom
> >
> > Infrastructure Engineer
> > Campaign Monitor
> > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com)
> > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> >
> > On 6 March 2014 20:27, Aivars Irmejs [aiv...@gmail.com](mailto:aiv...@gmail.com) wrote:
> >
> > > RAM: 1.5 GB
> > > Heap: 700 Mb
> > > Index count: 303
> > > Document count ([http://h3.blumentals.net:9200/\_count](http://h3.blumentals.net:9200/_count) - like so?):
> > > 2400432 - which seems more than expected...
> > >
> > > Thanks,
> > > Aivars
> > >
> > > On Thursday, March 6, 2014 11:13:39 AM UTC+2, Mark Walkom wrote:
> > >
> > > > Can you provide node stats, RAM, heap size, document count, index size
> > > > etc?
> > > >
> > > > Regards,
> > > > Mark Walkom
> > > >
> > > > Infrastructure Engineer
> > > > Campaign Monitor
> > > > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com)
> > > > web: [www.campaignmonitor.com](http://www.campaignmonitor.com)
> > > >
> > > > On 6 March 2014 20:00, Aivars Irmejs [aiv...@gmail.com](mailto:aiv...@gmail.com) wrote:
> > > >
> > > > > I'll start with the fact that I tried Oracle Java and that didn't help.
> > > > >
> > > > > I did some graphing and here is some more information via bigdesk -
> > > > > the good, fresh state:
> > > > > [http://kaitnieks.com/images/elasticsearch\_good.png](http://kaitnieks.com/images/elasticsearch_good.png)
> > > > > The worsened state:
> > > > > [http://kaitnieks.com/images/elasticsearch\_less\_good.png](http://kaitnieks.com/images/elasticsearch_less_good.png)
> > > > > The images indeed show that GC is more active and the fight against
> > > > > heap memory limit occurs more often.
> > > > >
> > > > > The question is - why does it happen, knowing that Elasticsearch idles
> > > > > in both cases (in 2nd image it has finished its indexings and waiting for
> > > > > the next) and how to return to the good, clean state without restarting?
> > > > > Are there any commands to get rid of any caches etc (which I don't need)
> > > > > that might help?
> > > > >
> > > > > Thanks,
> > > > > Aivars
> > > > >
> > > > > On Wednesday, March 5, 2014 10:48:47 AM UTC+2, Aivars Irmejs wrote:
> > > > >
> > > > > > When I'm starting or restarting ES service, its CPU use hovers at 3%
> > > > > > CPU which is great. After some time and some use the CPU use will climb to
> > > > > > 30%-100% and stay about that level even when idle. The first time it
> > > > > > happens flushing helps - after the flush CPU level returns to the nice and
> > > > > > pleasant 3% but eventually even that stops helping and only the service
> > > > > > restart does the trick.
> > > > > >
> > > > > > 30%-100% CPU use could be tolerated theoretically since the server
> > > > > > has multiple CPUs, but it's a VPS and I don't want to use more resources
> > > > > > than I need. ES works perfectly with 3% CPU use before it starts
> > > > > > misbehaving.
> > > > > >
> > > > > > What I want to figure most of all is why that happens and ideally
> > > > > > make it stay at the 3% level all the time, but I'm not sure how to go about
> > > > > > debugging it.
> > > > > >
> > > > > > Hot threads: [hot threads · GitHub](https://gist.github.com/kaitnieks/9363338)
> > > > > > OpenJDK 1.7.0\_51
> > > > > > 1 node, 300 indices
> > > > > > multicast disabled
> > > > > > happens with and without network.tcp.blocking, but when
> > > > > > network.tcp.blocking is false, CPU use seems to be a little higher.
> > > > > >
> > > > > > Thanks,
> > > > > > Aivars
> > > > >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "elasticsearch" group.
> > > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > > msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40goo
> > > > > [glegroups.com](http://glegroups.com)[https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/89d01c07-6ccf-430e-9de0-bdbfb9dc6155%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > > .
> > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "elasticsearch" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%
> > > > [40googlegroups.com](http://40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/8e742649-16e8-43bc-802d-c180bbfcddbb%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > .
> > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> > To view this discussion on the web visit
> > [https://groups.google.com/d/msgid/elasticsearch/a65fa610-ecdc-47a5-9fd3-72ffb38318c6%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/a65fa610-ecdc-47a5-9fd3-72ffb38318c6%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/a65fa610-ecdc-47a5-9fd3-72ffb38318c6%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/a65fa610-ecdc-47a5-9fd3-72ffb38318c6%40googlegroups.com?utm_medium=email&utm_source=footer)
> > .
> > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEM624bxtbRksNRGF7g5Fattcg87euRc4cZBYpF-Y-KfkMm1ag%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624bxtbRksNRGF7g5Fattcg87euRc4cZBYpF-Y-KfkMm1ag%40mail.gmail.com).
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).
---
### Author:  [@Aivars\_Irmejs](https://discuss.elastic.co/u/Aivars_Irmejs)
#### Post date: [March 7, 2014, 12:12am UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/14 "2014-03-07T00:12:07Z")
After some aggressive limiting I think I have managed to get what I wanted.
I think it was one of the caches, probably field cache that was eating up
all the memory and never letting it go.
If someone has a similar problem and similar use case (daily-weekly
reindexing, not that much searches), maybe this can help you:
threadpool.index.size: 4
threadpool.search.size: 10
threadpool.suggest.size: 2
threadpool.get.size: 3
threadpool.bulk.size: 2
threadpool.percolate.size: 2
threadpool.warmer.type: fixed
threadpool.warmer.size: 5
threadpool.refresh.type: fixed
threadpool.refresh.size: 5
indices.fielddata.cache.size: 20%
indices.fielddata.cache.expire: 4m
index.cache.filter.max\_size: 15
indices.cache.filter.expire: 4m
index.refresh\_interval: 5s
index.translog.flush\_threshold\_size: 30mb
indices.memory.index\_buffer\_size: 20%
indices.memory.min\_shard\_index\_buffer\_size: 1mb
indices.memory.min\_index\_buffer\_size: 1mb
I suspect that indices.fielddata was it, but I'm throwing in other
settings, too, just in case it's a combination of settings that works.
Regards,
Aivars
On Wednesday, March 5, 2014 10:48:47 AM UTC+2, Aivars Irmejs wrote:
> When I'm starting or restarting ES service, its CPU use hovers at 3% CPU
> which is great. After some time and some use the CPU use will climb to
> 30%-100% and stay about that level even when idle. The first time it
> happens flushing helps - after the flush CPU level returns to the nice and
> pleasant 3% but eventually even that stops helping and only the service
> restart does the trick.
>
> 30%-100% CPU use could be tolerated theoretically since the server has
> multiple CPUs, but it's a VPS and I don't want to use more resources than I
> need. ES works perfectly with 3% CPU use before it starts misbehaving.
>
> What I want to figure most of all is why that happens and ideally make it
> stay at the 3% level all the time, but I'm not sure how to go about
> debugging it.
>
> Hot threads: [hot threads · GitHub](https://gist.github.com/kaitnieks/9363338)
> OpenJDK 1.7.0\_51
> 1 node, 300 indices
> multicast disabled
> happens with and without network.tcp.blocking, but when
> network.tcp.blocking is false, CPU use seems to be a little higher.
>
> Thanks,
> Aivars
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/abf04730-57ce-447c-bc61-d09ec95005ef%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/abf04730-57ce-447c-bc61-d09ec95005ef%40googlegroups.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@Aivars\_Irmejs](https://discuss.elastic.co/u/Aivars_Irmejs)
#### Post date: [March 9, 2014, 2:45pm UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/15 "2014-03-09T14:45:33Z")
Unfortunately this is still not ideal... ☹ Elasticsearch is behaving well
for much, much longer now, but eventually CPU use rises and looking at
BigDesk I can see 2 things:
1. GC is actively clearing Old Gen objects (which I assume causes CPU load)
2. Heap memory rises up much, much steeper compared to when just launched,
even is ES is idling (which, I assume causes much more vigorous GC activity)
Can anyone explain me:
1. Why does heap memory rise at all when ES is idling?
2. Is there a way to get a good picture of what takes how much of heap
memory exactly?
Thanks,
Aivars
P.S. Turns out I only have 50,000 documents, the 2 million came from a
plugin that didn't have the courtesy to delete it's thrash during uninstall.
On Wednesday, March 5, 2014 10:48:47 AM UTC+2, Aivars Irmejs wrote:
> When I'm starting or restarting ES service, its CPU use hovers at 3% CPU
> which is great. After some time and some use the CPU use will climb to
> 30%-100% and stay about that level even when idle. The first time it
> happens flushing helps - after the flush CPU level returns to the nice and
> pleasant 3% but eventually even that stops helping and only the service
> restart does the trick.
>
> 30%-100% CPU use could be tolerated theoretically since the server has
> multiple CPUs, but it's a VPS and I don't want to use more resources than I
> need. ES works perfectly with 3% CPU use before it starts misbehaving.
>
> What I want to figure most of all is why that happens and ideally make it
> stay at the 3% level all the time, but I'm not sure how to go about
> debugging it.
>
> Hot threads: [hot threads · GitHub](https://gist.github.com/kaitnieks/9363338)
> OpenJDK 1.7.0\_51
> 1 node, 300 indices
> multicast disabled
> happens with and without network.tcp.blocking, but when
> network.tcp.blocking is false, CPU use seems to be a little higher.
>
> Thanks,
> Aivars
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/52853e2e-09e3-4c7c-b9f8-8122d378e929%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/52853e2e-09e3-4c7c-b9f8-8122d378e929%40googlegroups.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 1:44am UTC](https://discuss.elastic.co/t/help-me-debug-cpu-use-issues/16161/16 "2017-07-06T01:44:35Z")