# Deleting and creating indexes over time kills index performance

**URL:** <https://discuss.elastic.co/t/deleting-and-creating-indexes-over-time-kills-index-performance/38737>\
**Category:** Elasticsearch\
**Created:** [January 8, 2016, 2:50pm UTC](https://discuss.elastic.co/t/deleting-and-creating-indexes-over-time-kills-index-performance/38737 "2016-01-08T14:50:33Z")\
**Posts on this page:** 5\
**Page:** 2

<div class="post-metadata">

**Author:** ![jasontedor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jasontedor/32/66992_2.png) [@jasontedor](https://discuss.elastic.co/u/jasontedor)\
**Post date:** [January 28, 2016, 8:00pm UTC](https://discuss.elastic.co/t/deleting-and-creating-indexes-over-time-kills-index-performance/38737/21 "2016-01-28T20:00:41Z")

</div>

> [@haldrich](#):
>
> Is there some place specifically I should look for GC issues? None of the logs reference what I would take as a GC issue...

The Elasticsearch logs will show long GC pauses if they are occurring. An alternative that gives more detail is to enable GC logging. If you can turn on even simple GC logging (`-verbose:gc -XX:+PrintGCDateStamps -Xloggc:<path>`) that should be more than enough to rule out or give evidence for GC.

---

<div class="post-metadata">

**Author:** ![haldrich](https://avatars.discourse-cdn.com/v4/letter/h/b19c9b/32.png) [@haldrich](https://discuss.elastic.co/u/haldrich)\
**Post date:** [January 28, 2016, 9:43pm UTC](https://discuss.elastic.co/t/deleting-and-creating-indexes-over-time-kills-index-performance/38737/22 "2016-01-28T21:43:10Z")

</div>

Good to know... we can ignore it until the next release...

---

<div class="post-metadata">

**Author:** ![haldrich](https://avatars.discourse-cdn.com/v4/letter/h/b19c9b/32.png) [@haldrich](https://discuss.elastic.co/u/haldrich)\
**Post date:** [January 28, 2016, 9:46pm UTC](https://discuss.elastic.co/t/deleting-and-creating-indexes-over-time-kills-index-performance/38737/23 "2016-01-28T21:46:10Z")

</div>

I may be able to enable that when we do our next rolling restart... in the mean time, I double checked... not a single mention of the term 'garbage' in our logs. Aside from the monitor error, the logs are pretty clean.

---

<div class="post-metadata">

**Author:** ![jasontedor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jasontedor/32/66992_2.png) [@jasontedor](https://discuss.elastic.co/u/jasontedor)\
**Post date:** [January 29, 2016, 1:21am UTC](https://discuss.elastic.co/t/deleting-and-creating-indexes-over-time-kills-index-performance/38737/24 "2016-01-29T01:21:06Z")

</div>

> [@haldrich](#):
>
> I may be able to enable that when we do our next rolling restart... in the mean time, I double checked... not a single mention of the term 'garbage' in our logs. Aside from the monitor error, the logs are pretty clean.

If there is anything in the logs, it can be found by the regex `gc.*duration`. Also, you can get a _rough_ idea of garbage collection times by looking at `_node/stats` and grabbing the `jvm` and `gc` objects from the response.

---

<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:** [July 5, 2017, 11:20pm UTC](https://discuss.elastic.co/t/deleting-and-creating-indexes-over-time-kills-index-performance/38737/25 "2017-07-05T23:20:34Z")

</div>

Closed on July 5, 2017, 11:20pm UTC



[Previous page](https://discuss.elastic.co/t/deleting-and-creating-indexes-over-time-kills-index-performance/38737.md?page=1)
