.dropCollection() potential bug

MongoDB Percona Server for MongoDB
1

There seems to be a bug where doing .dropCollection() and then immediately recreating the collection does not seem to release space back to OS. This was encountered where a collection was dropped and immediately remade with the same indexes in order to free space. But this then required a server restart in order for the space to be released back to the OS.

The MongoDB server was in a replica set.

Is this a known bug?

2

It might be a bug. Please open a report at jira.percona.com with details so the dev team can take a look

3

hi @rkamath have you been able to create a bug for this?

4

https://perconadev.atlassian.net/browse/PSMDB-1480
I created it here although I’m not sure if this was the right place or not.

5

Perfect! It’s in the right project - thank you - I was not able to find it. I’ll provide you an update as soon as I can.

1 Like
6

@rkamath - this is an expected behavior in MongoDB. MongoDB seldom returns disk space to the operating system during deleting, these disk pages are marked dirty and reserved for writing in the future. The compact command lets WiredTiger return this space. (like PostgreSQL’s Vacuum). Note, that the compact command needs to be executed on every node in the cluster. Alternatively, you can resync a replicate set member (what you actually did by restarting the node).

See also MongoDB docs:

How do I reclaim disk space in WiredTiger?

The WiredTiger storage engine maintains lists of empty records in data files as it deletes documents. This space can be reused by WiredTiger, but will not be returned to the operating system unless under very specific circumstances.

The amount of empty space available for reuse by WiredTiger is reflected in the output of db.collection.stats() under the heading wiredTiger.block-manager.file bytes available for reuse.

To allow the WiredTiger storage engine to release this empty space to the operating system, you can de-fragment your data file. This can be achieved by resyncing a replica set member or using the compact command.

7

Hello @rkamath

If I understand correctly the issue is about filesystem space not freeing immediately after drop.

This is probably because MongoDB has two phase drop implementation. At first phase collection and its indexes are removed from metadata (but files are still preserved). At second phase files are removed from the filesystem. In the most common case second phase is deferred until the next checkpoint. By default MongoDB does checkpoints every 60 seconds.

That means it does not matter if you recreate collection with the same name or not. In any case old collection’s files will be removed after up to 60 seconds delay.

Please let us know if this corresponds to your observations.

8

I wasn’t able to test the exact delay but I’ll just try having a longer delay next time to see if that works. Thanks.