vinyl: keep track of compaction queue length
Currently, there's no way to figure out whether compaction keeps up with dumps or not while this is essential for implementing transaction throttling. This patch adds a metric that is supposed to help answer this question. This is the compaction queue size. It is calculated per range and per LSM tree as the total size of slices awaiting compaction. We update the metric along with the compaction priority of a range, in vy_range_update_compact_priority(), and account it to an LSM tree in vy_lsm_acct_range(). For now, the new metric is reported only on per index basis, in index.stat() under disk.compact.queue.
Showing
- src/box/vinyl.c 1 addition, 0 deletionssrc/box/vinyl.c
- src/box/vy_lsm.c 6 additions, 0 deletionssrc/box/vy_lsm.c
- src/box/vy_lsm.h 14 additions, 2 deletionssrc/box/vy_lsm.h
- src/box/vy_range.c 10 additions, 3 deletionssrc/box/vy_range.c
- src/box/vy_range.h 2 additions, 0 deletionssrc/box/vy_range.h
- src/box/vy_scheduler.c 7 additions, 2 deletionssrc/box/vy_scheduler.c
- src/box/vy_stat.h 2 additions, 0 deletionssrc/box/vy_stat.h
- src/errinj.h 1 addition, 0 deletionssrc/errinj.h
- test/box/errinj.result 3 additions, 1 deletiontest/box/errinj.result
- test/vinyl/errinj.result 94 additions, 0 deletionstest/vinyl/errinj.result
- test/vinyl/errinj.test.lua 27 additions, 0 deletionstest/vinyl/errinj.test.lua
- test/vinyl/info.result 10 additions, 0 deletionstest/vinyl/info.result
Loading
Please register or sign in to comment