Mirza, sure. Will wait for your review.
пн, 25 янв. 2021 г. в 11:06, Mirza Aliev :
> Hello, Alexey!
>
> Thank you for your effort, the feature looks great!
>
> Could you please give a bit more time to review it?
>
> Best regards,
> Mirza Aliev
>
> пт, 22 янв. 2021 г. в 10:19, Alex Plehanov :
>
>
Hello, Alexey!
Thank you for your effort, the feature looks great!
Could you please give a bit more time to review it?
Best regards,
Mirza Aliev
пт, 22 янв. 2021 г. в 10:19, Alex Plehanov :
> Hello, Igniters!
>
> Zhenya has already approved the patch that adds segmented-LRU and CLOCK
> page re
Hello, Igniters!
Zhenya has already approved the patch that adds segmented-LRU and CLOCK
page replacement modes [1] (thanks for the review!). Would anyone else like
to review it?
I have plans to merge it next Monday if nobody else will be interested in
reviewing it.
[1]: https://issues.apache.org
Guys,
I've implemented Segmented-LRU page replacement algorithm and benchmarked
results, it gives some boost (5-10%) when page replacement is
heavily used, but, unfortunately, when replacement is not used it gives
about 2% drop compared to the current Random-LRU page replacement
implementation. Du
Nikolay, i hope such case ignite users already observed)
I suggest to: put data bigger then available, full scan, get data only for
available inmem data in loop, check PageReplacement metric, how match
iterations will bring to zero this metric.
>Hello, Alex.
>
>> Perhaps we can implement
Nikolay,
> Can you list disadvantages of the Random-LRU?
Already described this in previous letters: "To find the next page for
replacement in the best case we scan 5 pages, in the worst case we can scan
all data region segment. Also, due to random nature, it's not very
effective in predicting the
Hello, Alex.
> Perhaps we can implement a special benchmark for this case with manually
> triggered "batch page replacement" using yardstick (but I'm not sure if
> ducktape can help here).
I think we should carefully describe the issues with the current approach and
then we can choose right to
Nikolay, Zhenya,
Benchmark from IGNITE-13034 is fully synthetic, it makes random puts
uniformly. It can be used to compare different page replacement algorithms
(random-LRU vs segmented-LRU), but it is totally inapplicable to benchmark
batch page replacement.
Perhaps we can implement a special ben
>Zhenya,
>
>> Alexey, we already have changes that partially fixes this issue [1]
>IGNITE-13086 it's a minor improvement. We still have major problems with
>our page replacement algorithm (slow page selection and non-optimal
>page-fault rate). I think changing from random 5 pages to 7 will m
Hello, Alex.
Do you have a reproducer for a Page memory issues, you described?
What is consequences of that types of issues?
Can we create some «benchmark» that will measure imrpovements of page
replacement algorithm?
May be we can use ducktape branch for it?
> 20 нояб. 2020 г., в 12:05, Alex
Zhenya,
> Alexey, we already have changes that partially fixes this issue [1]
IGNITE-13086 it's a minor improvement. We still have major problems with
our page replacement algorithm (slow page selection and non-optimal
page-fault rate). I think changing from random 5 pages to 7 will make
things ev
Alexey, we already have changes that partially fixes this issue [1]
Easy way:
Looks like we already have converge in page replacement.
If we change 5 times touch iterator from random lru algo into, for example — 7
we will obtain fast improvement from scratch.
» Batch page replacement
This appro
Hello, Igniters!
Currently, for page replacement (page rotation between page-memory and
disk) we use Random-LRU algorithm. It has a low maintenance cost and
relatively simple implementation, but it has many disadvantages and affects
performance very much when replacement is started. We even have w
13 matches
Mail list logo
