Re: [PROPOSAL] Change approach to store checkpoint recovery data

2023-12-07 Thread Alex Plehanov
Hello, Igniters! I've published benchmark results on the IEP page [1] Short summary: Storing recovery data on checkpoint can give performance boost (throughput) about 3-5%% in scenarios like IgnitePutBenchmark with default key range. In some extreme cases with heavy disk load it can provide even

Re: [PROPOSAL] Change approach to store checkpoint recovery data

2023-11-09 Thread Anton Vinogradov
Alex, agree to the proposal. On Thu, Nov 9, 2023 at 5:31 PM Alex Plehanov wrote: > Anton, > > Async physical logging is a target and most promising solution. > > In this scenario: > 1. Implement logical and physical records split. > 2. Implement async physical logging (actually, already

Re: [PROPOSAL] Change approach to store checkpoint recovery data

2023-11-09 Thread Alex Plehanov
Anton, Async physical logging is a target and most promising solution. In this scenario: 1. Implement logical and physical records split. 2. Implement async physical logging (actually, already implemented as PoC). 3. Drop solution, implemented in (1) after some time, if solution, implemented in

Re: [PROPOSAL] Change approach to store checkpoint recovery data

2023-11-09 Thread Anton Vinogradov
In this case, we can split logs to logical and physical at the initial fix. This should not cause any negative side effects. And, then implement an async physical logging as an alternative solution? On Thu, Nov 9, 2023 at 12:52 PM Alex Plehanov wrote: > Anton, > > My concern is not only about

Re: [PROPOSAL] Change approach to store checkpoint recovery data

2023-11-09 Thread Alex Plehanov
Anton, My concern is not only about compatibility. The new recovery data storing approach is not a silver bullet, it has drawbacks as well. Also, we can't be sure that the new approach is applicable for all environments: increased checkpoint time can lead to throttling or even OOM in some cases.

Re: [PROPOSAL] Change approach to store checkpoint recovery data

2023-11-03 Thread Anton Vinogradov
Sounds good to me, except the compatibility proposal. No need to keep the old behaviour. Noone will update the node after the crash. Update must happen only after the plain node stop, let's just check this instead of groving the code complexity. On Thu, Nov 2, 2023 at 4:55 PM Alex Plehanov

[PROPOSAL] Change approach to store checkpoint recovery data

2023-11-02 Thread Alex Plehanov
Hello, Igniters! I'd like to discuss the way of storing checkpoint recovery data. Now, we are writing extra data to WAL files to protect from failures during checkpoints. Later, we read and write WAL files with this extra data a couple of times, causing excessive disk load, which can lead to