You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some situations, the correct way to resolve a MimirCompactorHasNotSuccessfullyRunCompaction alert is to set the compactor.max-compaction-time flag so that only a smaller (several hours) amount of time is spent during the compaction cycle for a single tenant. Per the docs for the flag:
This can help in multi-tenant environments to avoid single tenant using
all compaction time, but also in single-tenant environments to force new
discovery of blocks more often
One instance of the alert triggering was a large number of "backfilled" blocks for a single tenant, monopolizing compactor time.
The text was updated successfully, but these errors were encountered:
I would argue we should set a reasonable default for that flag. For example, there's no real performance impact (with regards to object storage API calls and overhead in compaction) if we set it to something between 1h and 2h, but would be a better default.
In some situations, the correct way to resolve a
MimirCompactorHasNotSuccessfullyRunCompaction
alert is to set thecompactor.max-compaction-time
flag so that only a smaller (several hours) amount of time is spent during the compaction cycle for a single tenant. Per the docs for the flag:One instance of the alert triggering was a large number of "backfilled" blocks for a single tenant, monopolizing compactor time.
The text was updated successfully, but these errors were encountered: