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)

Most upvoted comments

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!