99% sure it’s background merging. When two segments are merged, the combined segment is written and only after it’s successful will the old segments be deleted.
Restarting will stop any ongoing merging and delete any un-referenced segments. I expect you’ll see the space come back as you start indexing again. For this reason, it’s required that _at least_ as much free space exists on the disk as the index occupies, and maybe 2x. IOW, this is normal operation at this point. Especially if you optimize (which I recommend against) then I practically guarantee that you’ll need as much free space on your disk as the index size. Best, Erick > On Mar 21, 2019, at 9:44 AM, SOLR4189 <klin892...@yandex.ru> wrote: > > Hi all. > We use SOLR-6.5.1 and in our cluster each solr core is placed in different > virtual machine (one core per one node). Each virtual machine has 104 Gb > size of disk. > Yesterday we marked that several solr cores use disk space in the abnormal > manner. > In running command *"df -h > /opt/solr/CollectionName_shardX_replicaY/data/index"* we saw that 92GB of > disk is occupied, but size of index in this machine is 62GB by solr cloud > (also by command *"ls -l > /opt/solr/CollectionName_shardX_replicaY/data/index"*). After restart solr > service, df -h also reports 62GB occupied place in disk. > > Does somebody know what is it? > Can it be somehow connected to our deletes? (we run each night delete by > query command for deleting expired documents)? > > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
