[
https://issues.apache.org/jira/browse/OAK-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-5056:
-------------------------------
Description:
This issue is about making TarMK gc more scalable:
* how to deal with huge repositories.
* how to deal with massive concurrent writes.
* how can we improve monitoring to determine gc health.
** Monitor deduplication caches (e.g. deduplication of checkpoints)
Possible avenues to explore:
* Can we partition gc? (e.g. along sub-trees, along volatile vs. static content)
* Can we pause and resume gc? (e.g. to give precedence to concurrent writes)
* Can we make gc a real background process not contending with foreground
operations?
This issue is a follow up to OAK-2849, which was about efficacy of gc.
was:
This issue is about making TarMK gc more scalable:
* how to deal with huge repositories.
* how to deal with massive concurrent writes.
Possible avenues to explore:
* Can we partition gc? (e.g. along sub-trees, along volatile vs. static content)
* Can we pause and resume gc? (e.g. to give precedence to concurrent writes)
* Can we make gc a real background process not contending with foreground
operations?
This issue is a follow up to OAK-2849, which was about efficacy of gc.
> Improve GC scalability on TarMK
> -------------------------------
>
> Key: OAK-5056
> URL: https://issues.apache.org/jira/browse/OAK-5056
> Project: Jackrabbit Oak
> Issue Type: Epic
> Components: segment-tar
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Labels: gc, scalability
> Fix For: 1.8
>
>
> This issue is about making TarMK gc more scalable:
> * how to deal with huge repositories.
> * how to deal with massive concurrent writes.
> * how can we improve monitoring to determine gc health.
> ** Monitor deduplication caches (e.g. deduplication of checkpoints)
> Possible avenues to explore:
> * Can we partition gc? (e.g. along sub-trees, along volatile vs. static
> content)
> * Can we pause and resume gc? (e.g. to give precedence to concurrent writes)
> * Can we make gc a real background process not contending with foreground
> operations?
> This issue is a follow up to OAK-2849, which was about efficacy of gc.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
