# Big uncommitted segments to disk reported by GET /myIndex/\_segments API (ES version 6.3) **URL:** \ **Category:** Elasticsearch\ **Created:** [June 18, 2020, 1:32pm UTC](https://discuss.elastic.co/t/big-uncommitted-segments-to-disk-reported-by-get-myindex-segments-api-es-version-6-3/237648 "2020-06-18T13:32:48Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Spico\_Florin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spico_florin/32/49309_2.png) [@Spico\_Florin](https://discuss.elastic.co/u/Spico_Florin)\ **Post date:** [June 18, 2020, 1:32pm UTC](https://discuss.elastic.co/t/big-uncommitted-segments-to-disk-reported-by-get-myindex-segments-api-es-version-6-3/237648/1 "2020-06-18T13:32:48Z")
Hello! WE are using ElasticSearch version 6.3. We have one situation were the GET /myIndex/\_segments API reported some big size files that are uncommitted to disk (the committed field of the mentioned API is false, see the attached picture). Another aspect, is that we also have in these segments a huge number of updated files (we know they are updated and not deleted). My questions are: 1. What can cause that these segments do not be committed to disk? 2. How this situation can impact for example search performance? 3. What can prevent merging of segments? 4. After the merging, the deleted number of documents should be decrease, isn't it? ![myIndexBigSegments](https://us1.discourse-cdn.com/elastic/original/3X/1/9/1966213c7ae33c35f40761870c491b87ffaf8e59.png) ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 16, 2020, 1:32pm UTC](https://discuss.elastic.co/t/big-uncommitted-segments-to-disk-reported-by-get-myindex-segments-api-es-version-6-3/237648/2 "2020-07-16T13:32:53Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.