Skip to content

improve: change scheduleAtFixedRate to scheduleWithFixedDelay in GarbageCollectorThread#4296

Merged
hezhangjian merged 1 commit into
apache:masterfrom
hezhangjian:gcwaittime
Apr 20, 2024
Merged

improve: change scheduleAtFixedRate to scheduleWithFixedDelay in GarbageCollectorThread#4296
hezhangjian merged 1 commit into
apache:masterfrom
hezhangjian:gcwaittime

Conversation

@hezhangjian

@hezhangjian hezhangjian commented Apr 16, 2024

Copy link
Copy Markdown
Member

Motivation

Current scheduling mechanism for garbage collection uses scheduleAtFixedRate. This approach schedules the next execution without considering whether the current task has finished, potentially leading to overlapping executions if a task takes longer than expected.

In my test environment, After task accumulation in gc thread pool, sometimes there is no entrylog to extract and no entrylogger to compact. But every round of gc, still need to compare ledger meta between local and metadata store (zk), which will result in highly frequently access to metadata store and each access will bring considerable unnecessary data flow.

See https://lists.apache.org/thread/023vkc5rwyq0j776zcv8dtp7c8cml6vp

…ageCollectorThread

Signed-off-by: ZhangJian He <shoothzj@gmail.com>

@eolivelli eolivelli left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@hezhangjian

Copy link
Copy Markdown
Member Author

@nicoloboschi @eolivelli @hangc0276 @merlimat @zhaijack @dlg99 PTAL

@hangc0276 hangc0276 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

@hezhangjian
hezhangjian merged commit f62a81d into apache:master Apr 20, 2024
@hezhangjian
hezhangjian deleted the gcwaittime branch April 20, 2024 00:14
hezhangjian pushed a commit that referenced this pull request May 25, 2024
…ageCollectorThread (#4296)

### Motivation

Current scheduling mechanism for garbage collection uses scheduleAtFixedRate. This approach schedules the next execution without considering whether the current task has finished, potentially leading to overlapping executions if a task takes longer than expected.

In my test environment, After task accumulation in gc thread pool, sometimes there is no entrylog to extract and no entrylogger to compact. But every round of gc, still need to compare ledger meta between local and metadata store (zk), which will result in highly frequently access to metadata store and each access will bring considerable unnecessary data flow.

See https://lists.apache.org/thread/023vkc5rwyq0j776zcv8dtp7c8cml6vp

Signed-off-by: ZhangJian He <shoothzj@gmail.com>
(cherry picked from commit f62a81d)
hezhangjian pushed a commit that referenced this pull request May 25, 2024
…ageCollectorThread (#4296)

### Motivation

Current scheduling mechanism for garbage collection uses scheduleAtFixedRate. This approach schedules the next execution without considering whether the current task has finished, potentially leading to overlapping executions if a task takes longer than expected.

In my test environment, After task accumulation in gc thread pool, sometimes there is no entrylog to extract and no entrylogger to compact. But every round of gc, still need to compare ledger meta between local and metadata store (zk), which will result in highly frequently access to metadata store and each access will bring considerable unnecessary data flow.

See https://lists.apache.org/thread/023vkc5rwyq0j776zcv8dtp7c8cml6vp

Signed-off-by: ZhangJian He <shoothzj@gmail.com>
(cherry picked from commit f62a81d)
Ghatage pushed a commit to sijie/bookkeeper that referenced this pull request Jul 12, 2024
…ageCollectorThread (apache#4296)

### Motivation

Current scheduling mechanism for garbage collection uses scheduleAtFixedRate. This approach schedules the next execution without considering whether the current task has finished, potentially leading to overlapping executions if a task takes longer than expected.

In my test environment, After task accumulation in gc thread pool, sometimes there is no entrylog to extract and no entrylogger to compact. But every round of gc, still need to compare ledger meta between local and metadata store (zk), which will result in highly frequently access to metadata store and each access will bring considerable unnecessary data flow.

See https://lists.apache.org/thread/023vkc5rwyq0j776zcv8dtp7c8cml6vp

Signed-off-by: ZhangJian He <shoothzj@gmail.com>
lhotari pushed a commit that referenced this pull request Apr 17, 2025
…ageCollectorThread (#4296)

### Motivation

Current scheduling mechanism for garbage collection uses scheduleAtFixedRate. This approach schedules the next execution without considering whether the current task has finished, potentially leading to overlapping executions if a task takes longer than expected.

In my test environment, After task accumulation in gc thread pool, sometimes there is no entrylog to extract and no entrylogger to compact. But every round of gc, still need to compare ledger meta between local and metadata store (zk), which will result in highly frequently access to metadata store and each access will bring considerable unnecessary data flow.

See https://lists.apache.org/thread/023vkc5rwyq0j776zcv8dtp7c8cml6vp

Signed-off-by: ZhangJian He <shoothzj@gmail.com>
(cherry picked from commit f62a81d)
@hangc0276 hangc0276 added this to the 4.18.0 milestone May 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants