I am using mongo v3.4.10 with WiredTiger. I run the following command:
db.runCommand({ compact: "my_collection" });
the response is:
/* 1 */
{
"ok" : 1.0
}
and the mongo log shows:
2017-10-31T00:12:20.282+0000 I COMMAND [conn23] compact mydb.my_collection begin, options: paddingMode: NONE validateDocuments: 1
2017-10-31T00:12:21.662+0000 I COMMAND [conn23] compact mydb.my_collection end
2017-10-31T00:12:21.663+0000 I COMMAND [conn23] command mydb.my_collection appName: "MongoDB Shell" command: compact { compact: "my_collection" } numYields:0 reslen:22 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { W: 1 } } } protocol:op_command 1381ms
In short, everything looks fine, but the storageSize is exactly the same :/
I deleted lots of fields with a value of
null
, so I would expect a **significant** drop in disk usage.
I read online that early v3 had issues with this, but I'm on the latest version right now. The database is quite large so if I can avoid repairDatabase
that would be good.
Any help is appreciated, thx.
----------
UPDATE: I performed a mongodump / mongorestore, and it resulted in a 9% disk use reduction (admittedly I was expecting more). Nonetheless, it seems like compact *should* have had an impact.
UPDATE 2: I performed a repairDatabase and it had no effect. This is explicitly stated in mongo docs (https://docs.mongodb.com/manual/reference/command/repairDatabase) :
> For WiredTiger, the operation rebuilds the database but does not result in the compaction of the collections in the database
but i thought i'd give it a crack. Still not sure why compact did nothing though.
Asked by mils
(175 rep)
Oct 31, 2017, 02:33 AM
Last activity: Sep 8, 2020, 05:05 PM
Last activity: Sep 8, 2020, 05:05 PM