pebble: Performance degradation on massive writing
Hello, we are importing large amount of data (261,000,000 records) into the pebble database - we write them using Put operation. The performance of writes degrades and new writes takes more and more time. From the metrics table we see the level 0 becomes huge and it is probably the cause.
- Closing and reopening the database does not help
- Enclosing writes into batches did not help
- When we run
db.Compact([]byte{0x00}, []byte{0xFF})
in the middle of the import, it becomes fast again - Without compact, the import takes 25 hours
- When we run Compact ± every 1 minute, it is finished in 3 hours (the Compacts time included)
I believe this is a performance bug of pebble. Is there something we should check?
Thanks
Metrics (without calling Compact manually) - the level 0 grows to hundreds gigabytes:
__level_____count____size___score______in__ingest(sz_cnt)____move(sz_cnt)___write(sz_cnt)____read___r-amp___w-amp
WAL 2 6.3 M - 401 M - - - - 401 M - - - 1.0
0 387143 267 G 1.08 395 M 0 B 0 0 B 0 263 M 17 K 0 B 4 0.7
1 25 89 M 1.35 570 M 0 B 0 0 B 0 2.3 G 804 2.3 G 1 4.2
2 135 598 M 1.04 393 M 0 B 0 144 M 78 1.6 G 258 1.6 G 1 4.2
3 414 5.1 G 1.00 494 M 0 B 0 10 M 4 1.8 G 155 1.8 G 1 3.8
4 1841 45 G 0.97 368 M 0 B 0 4.0 M 1 1.4 G 60 1.4 G 1 4.0
5 16340 397 G 0.95 0 B 0 B 0 0 B 0 0 B 0 0 B 1 0.0
6 31725 3.4 T - 0 B 0 B 0 0 B 0 0 B 0 0 B 1 0.0
total 437623 4.1 T - 401 M 0 B 0 158 M 83 7.8 G 18 K 7.2 G 10 20.0
flush 112
compact 431 3.2 T 5.1 M 1 (size == estimated-debt, score = in-progress-bytes, in = num-in-progress)
ctype 348 0 0 83 0 0 (default, delete, elision, move, read, rewrite)
memtbl 2 8.0 M
zmemtbl 0 0 B
ztbl 0 0 B
bcache 0 0 B 59.8% (score == hit-rate)
tcache 1.9 K 1.2 M 89.8% (score == hit-rate)
snaps 1 - 17835168338 (score == earliest seq num)
titers 0
filter - - 0.0% (score == utility)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 18 (3 by maintainers)
Thank you, @nicktrav ! I have set the
MaxConcurrentCompactions
option to 10 and now no inverted LSM occures 👍Now, after 5 hours of inserting 12121600000 items (inserting faster by 72%), the LSM is OK. I am going to experiment to find the best value of the option for our purpose, but the issue seems resolved. Thank you very much!
With the new version, the performance degradation still occurs, but after a while it fixes by itself and returns to the original (good) performance. (We are inserting keys in ascending order, as they comes from iterator on the source server.) Seems good enough, I am closing this.
Thank you very much for your help!