Hi Andrey, Thanks for your feedback! Summarize the discussion in PR, if we try to support dynamically pause/resume major/minor compaction, the system will become more complex and hard to configure a reasonable threshold. Moreover, if we debug the removed ledger not cleaned up, it's hard to explain why the compaction service was suspended. So i prefer to make it simple. As you mention, we can use the rest api to support this, which is a practicable method. So we need to decide whether we should support this feature natively in bookie. And there is one more point: when should we add this check? There shouldn't be much controversy that we should check if at the beginning of the compaction, but should we check it each time before we try to compact a new entry log? If we stop the compaction at the running time, should we resume this major/minor compaction or just start a new compaction?
Thanks, Wenzhi Feng(thetumbled). On 2024/05/24 01:11:18 Andrey Yegorov wrote: > I am rather indifferent about the change. > There was an attempt in the to implement something similar: > https://github.com/apache/bookkeeper/pull/851 > > It was abandoned, as I remember, because the company where the author > worked had chosen to use REST API and cron to run enable/disable > compaction. > > So you already can disable the compaction on schedule just not via bookie > configuration. > > I'd support a mechanism that would dynamically pause/resume major/minor > compaction if the load on bookie is high (e.g. as tracked by pending > requests or request queue latency) if the disk space is enough. > > On Wed, May 22, 2024 at 3:27?6?2AM thetumbled <wo...@qq.com.invalid> wrote: > > > Hi all, > > I create a new BP to avoid executing compaction at busy times, Looking > > forward to your feedback. > > https://github.com/apache/bookkeeper/issues/4382 > > > > Thanks, > > Wenzhi Feng(thetumbled). > > > > -- > Andrey Yegorov ></wo...@qq.com.invalid>
