background space reclaim isn't working after DROP DATABASE

[hermanlee]

Issue by mdcallag
Tuesday Sep 15, 2015 at 14:55 GMT
Originally opened as MySQLOnRocksDB#111

---

My test loop ran 24 iterations and at the end of each iteration the database size is listed below. Each iteration is DROP DATABASE, create linkbench database and tables, linkbench load, linkbench run for 30 minutes. I used requesters=20 and maxid1=10M in the linkbench configuration. The database wasn't empty prior to the first iteration, so the size after one iteration was 46G and not something smaller.

46G /ssd1/scratch/data.mdcallag/data
51G /ssd1/scratch/data.mdcallag/data
55G /ssd1/scratch/data.mdcallag/data
59G /ssd1/scratch/data.mdcallag/data
63G /ssd1/scratch/data.mdcallag/data
68G /ssd1/scratch/data.mdcallag/data
72G /ssd1/scratch/data.mdcallag/data
76G /ssd1/scratch/data.mdcallag/data
81G /ssd1/scratch/data.mdcallag/data
85G /ssd1/scratch/data.mdcallag/data
89G /ssd1/scratch/data.mdcallag/data
93G /ssd1/scratch/data.mdcallag/data
97G /ssd1/scratch/data.mdcallag/data
102G /ssd1/scratch/data.mdcallag/data
106G /ssd1/scratch/data.mdcallag/data
110G /ssd1/scratch/data.mdcallag/data
114G /ssd1/scratch/data.mdcallag/data
119G /ssd1/scratch/data.mdcallag/data
123G /ssd1/scratch/data.mdcallag/data
126G /ssd1/scratch/data.mdcallag/data
130G /ssd1/scratch/data.mdcallag/data
134G /ssd1/scratch/data.mdcallag/data
138G /ssd1/scratch/data.mdcallag/data
142G /ssd1/scratch/data.mdcallag/data

[hermanlee]

Comment by yoshinorim
Tuesday Sep 15, 2015 at 17:41 GMT

---

Here is my understanding about what is going on:

• Created tables (and assigning index_ids in ascending order) and filled data. LinkBench created 4 index ids -- 256, 257, 258, 259.
• Ran DROP DATABASE. They dropped all tables within the database. Index ids 256-259 were not immediately compacted. They were supposed to be compacted, when associated sst files were selected as compaction targets.
• Created tables and filled data again. Created 4 index ids -- 260, 261, 262, 263.
• Ran DROP DATABASE. They dropped all tables within the database. Index ids 260-263 were not immediately compacted. They were supposed to be compacted, when associated sst files were selected as compaction targets.
  ....

Dropped index ids are never reused by existing/future tables. This means, sst files, where dropped index ids are stored, are very unlikely to be selected as compaction targets.

[yoshinorim]

https://reviews.facebook.net/D49107