[
https://issues.apache.org/jira/browse/HBASE-26987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17742817#comment-17742817
]
Duo Zhang commented on HBASE-26987:
-----------------------------------
So the problem here is that, when request system compaction, we set selectNow
to false to delay the actual file selecting, but if there is a slow compaction,
the system compaction request will be in a queue for a long time and we will
not select any files, so then, so when we want to request system compaction
again, we do not know there is already a pending one, then we will schedule a
new one soon, this makes the compaction queue grow too big?
Seems the problem is that, we should not queue another compaction request if
there is already one?
> The length of compact queue grows too big when the compacting is slow
> ---------------------------------------------------------------------
>
> Key: HBASE-26987
> URL: https://issues.apache.org/jira/browse/HBASE-26987
> Project: HBase
> Issue Type: Improvement
> Reporter: Zheng Wang
> Assignee: Zheng Wang
> Priority: Major
> Attachments: image-2022-04-29-10-26-09-351.png,
> image-2022-04-29-10-26-18-323.png, image-2022-04-29-10-26-24-087.png
>
>
> For some system compaction, we set the selectNow to false, so the file
> selecting will not be done until the compaction running, it brings side
> effect, if another compacting is slow, we may put lots of compaction to
> queue, because the filesCompacting of Hstore is empty in the meantime.
> An example shows at attachments, there are 154 regions and about 2000 hfiles,
> but the length of compact queue grows to 1391, it cause confusion and may
> trigger unexpected alarm.
> My approach is limit the compaction queue count, by compute the
> filesNotCompating and hbase.hstore.compaction.max.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
