Open ideawu opened 4 years ago
Well, there is 1946 files at level=0, that's because the database is just recovered from a repair.
What version of leveldb are you using?
@cmumford I am using version 1.20. here is more detail about how to reproduce the issue:
sprintf("%15d", end++)
and sprintf("%15d", start++)
When performing Seek("0"), leveldb will skips lots of continuous deleted keys in sst file.
I am running a leveldb instance with 30GB of data. Now it happens that Iterator::Seek() gets extremely slow, as slow as it takes several hours to finish.
The leveldb.stats is:
I debug it by adding some printf() codes, and find out
DBIter::FindNextUserEntry()
is the problem.Here is my code added:
after
https://github.com/google/leveldb/blob/5903e7a1125cacaa1d44367b5b84fe9208e42884/db/db_iter.cc#L188 https://github.com/google/leveldb/blob/5903e7a1125cacaa1d44367b5b84fe9208e42884/db/db_iter.cc#L193
Here is some outputs:
As the output shows, the keys are added and then deleted, but both remain in sst files, so DBIter skips them one by one before reaching at the target. For my use case, I deleted millions of keys, that's why it gets so slow, it iterates over millions of obsoleted keys on a hard disk!
So my question is, why shouldn't these keys be really "deleted"? They do not exist in the database scope, they are marked deleted in level-0 sst file, and they do not exist in higher level sst files, they should be really deleted after compaction.