# Elasticsearch 2.0 2.5X Disk Space

**URL:** <https://discuss.elastic.co/t/elasticsearch-2-0-2-5x-disk-space/34805>\
**Category:** Elasticsearch\
**Created:** [November 17, 2015, 1:32pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-2-5x-disk-space/34805 "2015-11-17T13:32:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Drew\_Town](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/drew_town/32/44829_2.png) [@Drew\_Town](https://discuss.elastic.co/u/Drew_Town)\
**Post date:** [November 17, 2015, 1:32pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-2-5x-disk-space/34805/1 "2015-11-17T13:32:39Z")

</div>

We utilize Elasticsearch primarily for Logstash data and with the recent upgrade to 2.0 we saw about a 2.5X disk space increase. Same data, same data types and fields.

logstash-2015.11.10 - 179.3m - 139.6GB

logstash-2015.11.16 - 174.3m - 411.5GB

Not so much a question but this is likely due to the Doc Values turned on for all non-analyzed fields by default where as before we were only use Doc Values for the @timestamp field.

---

<div class="post-metadata">

**Author:** ![rusty](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@rusty](https://discuss.elastic.co/u/rusty)\
**Post date:** [November 17, 2015, 2:14pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-2-5x-disk-space/34805/2 "2015-11-17T14:14:10Z")

</div>

We have the same results with ES 2.0. Now in research if we really needed doc\_values or not. Right now I don't see any benefit of it, because we don't use much aggregations or sorting for stored logs data. Just waste of disk space.

Did you try to use `settings.index.codec: "best_compression"` for new indexes? It can help you to minimize impact of doc\_values.

---

<div class="post-metadata">

**Author:** ![Drew\_Town](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/drew_town/32/44829_2.png) [@Drew\_Town](https://discuss.elastic.co/u/Drew_Town)\
**Post date:** [November 17, 2015, 2:20pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-2-5x-disk-space/34805/3 "2015-11-17T14:20:26Z")

</div>

Thanks for confirmation that you saw the same thing rusty. It's good to know that it wasn't just something in our cluster that went crazy. It is pretty nice how much more space is available on the heap but it is a huge increase in disk space usage.

I haven't tried the `settings.index.codec: "best_compression"` yet but was looking into it yesterday. Based on how this is looking it's probably a worthwhile change for me to do this weekend.

---

<div class="post-metadata">

**Author:** ![shanec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/shanec/32/4004_2.png) [@shanec](https://discuss.elastic.co/u/shanec)\
**Post date:** [November 17, 2015, 2:38pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-2-5x-disk-space/34805/4 "2015-11-17T14:38:22Z")

</div>

It certainly can increase disk space usage (if you didn't have doc values turned on before). However, many people are memory bound on their machines, and all that stuff that you now have on disk used to be in memory, which is _usually_ much more pricey. Also, by moving these out of memory and onto disk, some systems will be much more stable by avoiding out of memory exceptions. But each system is different and sometimes you have gobs of memory and no disk space left, so definitely something to be aware of!

---

<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:37pm UTC](https://discuss.elastic.co/t/elasticsearch-2-0-2-5x-disk-space/34805/5 "2017-07-05T23:37:55Z")

</div>


