compact() should not update queue lengths if a compaction has locked the files to be compacted #22138
Assignees
Labels
Comments
davidby-influx
added a commit
that referenced
this issue
Aug 9, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. closes #22138
davidby-influx
added a commit
that referenced
this issue
Aug 9, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. closes #22138
4 tasks
4 tasks
4 tasks
davidby-influx
added a commit
that referenced
this issue
Aug 12, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138
4 tasks
4 tasks
davidby-influx
added a commit
that referenced
this issue
Aug 16, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138
davidby-influx
added a commit
that referenced
this issue
Aug 16, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138 (cherry picked from commit 7d3efe1) closes #22139
4 tasks
davidby-influx
added a commit
that referenced
this issue
Aug 16, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138 (cherry picked from commit 7d3efe1) closes #22139
davidby-influx
added a commit
that referenced
this issue
Aug 17, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138 (cherry picked from commit 7d3efe1) closes #22141
4 tasks
davidby-influx
added a commit
that referenced
this issue
Aug 17, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138 (cherry picked from commit 7d3efe1) closes #22141
davidby-influx
added a commit
that referenced
this issue
Aug 17, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138 (cherry picked from commit 7d3efe1) closes #22141
davidby-influx
added a commit
that referenced
this issue
Aug 17, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138 (cherry picked from commit 7d3efe1) closes #22141
davidby-influx
added a commit
that referenced
this issue
Aug 17, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138 (cherry picked from commit 7d3efe1) closes #22141 (cherry picked from commit 9923d2e) closes #22142
4 tasks
davidby-influx
added a commit
that referenced
this issue
Aug 18, 2021
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. Instead, use the length of pending files which would have been returned. closes #22138 (cherry picked from commit 7d3efe1) closes #22141 (cherry picked from commit 9923d2e) closes #22142
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the compaction planner runs, if it cannot acquire a lock on the files it plans to compact, it returns a nil list of compaction groups. This, in turn, sets the engine statistics for compactions queues to zero, which is incorrect. This behavior results in misleading output like the following graph which alternates between ~1500 compactions in the queue and zero.
The text was updated successfully, but these errors were encountered: