Tens of GB indexes deleted, no OS space reclaimed

Elastic Stack Elasticsearch
1

Hi, I have scouted locals forum for almost half a day but no relevant reply found. I am trying to introduce curator to our ES and I have deleted several 25GB indexes successfully. However, no OS space reclaimed after deletion.

I haven't found much resources I could use to check the relevant parts. I am beginner in ES, hence I don't know much about the bits under the hood. Sorry.

I would be grateful for any advice pointing me in the right direction (i.e. what to check etc.)

My configuration is one-node Elasticsearch on Windows 2016.

EDIT: To give you as precise insight into the approach of mine as possible, I have done this to my server:

(.venv) D:\ELK\curator\.venv\Scripts>curator_cli --config _curator_config\curator-config.yml --username *redacted*--password *redacted* delete-indices --filter_list "[{\"filtertype\":\"age\",\"source\":\"creation_date\",\"direction\":\"older\",\"unit\":\"days\",\"unit_count\":30},{\"filtertype\":\"pattern\",\"kind\":\"prefix\",\"value\":\"xy-servers-\"}]"
2021-08-19 15:31:46,645 INFO      Instantiating client object
2021-08-19 15:31:46,646 INFO      Testing client connectivity
2021-08-19 15:31:46,653 INFO      Successfully created Elasticsearch client object with provided settings
d:\elk\curator\.venv\lib\site-packages\elasticsearch\connection\base.py:208: ElasticsearchWarning: this request accesses system indices: [.apm-agent-configuration, .apm-custom-link, .async-search, .kibana_1, .kibana_task_manager_1, .security-7], but in a future major version, direct access to system indices will be prevented by default
  warnings.warn(message, category=ElasticsearchWarning)
2021-08-19 15:31:46,916 INFO      Deleting 9 selected indices: ['xy-servers-2021.05.29-000025', 'xy-servers-2021.06.10-000027', 'xy-servers-2021.07.07-000032', 'xy-servers-2021.06.21-000029', 'xy-servers-2021.06.15-000028', 'xy-servers-2021.07.12-000033', 'xy-servers-2021.07.01-000031', 'xy-servers-2021.05.24-000024', 'xy-servers-2021.06.04-000026']
2021-08-19 15:31:46,917 INFO      ---deleting index xy-servers-2021.05.29-000025
2021-08-19 15:31:46,917 INFO      ---deleting index xy-servers-2021.06.10-000027
2021-08-19 15:31:46,917 INFO      ---deleting index xy-servers-2021.07.07-000032
2021-08-19 15:31:46,918 INFO      ---deleting index xy-servers-2021.06.21-000029
2021-08-19 15:31:46,919 INFO      ---deleting index xy-servers-2021.06.15-000028
2021-08-19 15:31:46,919 INFO      ---deleting index xy-servers-2021.07.12-000033
2021-08-19 15:31:46,921 INFO      ---deleting index xy-servers-2021.07.01-000031
2021-08-19 15:31:46,921 INFO      ---deleting index xy-servers-2021.05.24-000024
2021-08-19 15:31:46,922 INFO      ---deleting index xy-servers-2021.06.04-000026
2021-08-19 15:32:00,089 INFO      "delete_indices" action completed.

After this (deleted a lot over 100GB), not even a single GB has been added to free space on the D:\ drive (where does whole ELK reside).

Thanks in advance for any feedback.

2

... and on the server in different subsidiary I have configured (the configuration is identical as far as I am concerned), the reclaim is almost instant ...

3

Welcome to our community! :smiley:

What version of Elasticsearch are you using?

4

Hello Mark, thanks for the interest into this problem of mine. We use 7.10.1 on both servers.

5

It is not Elasticsearch issue, rather filesystem issue - the size of the ELK folder changes with respect to index deletions via curator. Nevermind, closing the ticket.

1 Like
6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.