You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Ivan Bessonov (Jira)" <ji...@apache.org> on 2024/01/11 08:45:00 UTC

[jira] [Updated] (IGNITE-21234) Acquired checkpoint read lock waits for schedules checkpoint write unlock sometimes

     [ https://issues.apache.org/jira/browse/IGNITE-21234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivan Bessonov updated IGNITE-21234:
-----------------------------------
    Summary: Acquired checkpoint read lock waits for schedules checkpoint write unlock sometimes  (was: Checkpoint read lock waits for checkpoint write unlock sometimes)

> Acquired checkpoint read lock waits for schedules checkpoint write unlock sometimes
> -----------------------------------------------------------------------------------
>
>                 Key: IGNITE-21234
>                 URL: https://issues.apache.org/jira/browse/IGNITE-21234
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Ivan Bessonov
>            Assignee: Ivan Bessonov
>            Priority: Major
>              Labels: ignite-3
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> In a situation where we have "too many dirty pages" we trigger checkpoint and wait until it starts. This can take seconds, because we have to flush free-lists before acquiring checkpoint write lock. This can cause severe dips in performance for no good reason.
> I suggest introducing two modes for triggering checkpoints when we have too many dirty pages: soft threshold and hard threshold.
>  * soft - trigger checkpoint, but don't wait for its start. Just continue all operations as usual. Make it like a current threshold  - 75% of any existing memory segment must be dirty.
>  * hard - trigger checkpoint and wait until it starts. The way it behaves right now. Make it higher than current threshold - 90% of any existing memory segment must be dirty.
> Maybe we should use different values for thresholds, that should be discussed during the review



--
This message was sent by Atlassian Jira
(v8.20.10#820010)