Re: [Patch][WiP] Tweaked LRU for shared buffers

Hi Tomas,

If you are on a benchmarking binge and feel like generating some trace
files (as mentioned earlier), I'd be happy to help in regards to running
them through simulations to show how different policies behave. We can add
more types to match this patch / Postgres' GClock as desired, too.

On Tue, Feb 26, 2019 at 3:04 PM Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:

> On 2/17/19 2:53 PM, Tomas Vondra wrote:
> > On 2/17/19 2:14 PM, Едигарьев, Иван Григорьевич wrote:
> >> Hi there. I was responsible for the benchmarks, and I would be glad to
> >> make clear that part for you.
> >>
> >> On Sat, 16 Feb 2019 at 02:30, Tomas Vondra <
> tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> >>> Interesting. Where do these numbers (5/8 and 1/8) come from?
> >>
> >> The first number came from MySQL realization of LRU algorithm
> >> <https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html>
> >> and the second from simple tuning, we've tried to change 1/8 a little,
> >> but it didn't change metrics significantly.
> >>
> >>> That TPS chart looks a bit ... wild. How come the master jumps so much
> >>> up and down? That's a bit suspicious, IMHO.
> >>
> >> Yes, it is. It would be great if someone will try to reproduce those
> results.
> >>
> >
> > I'll try.
> >
>
> I've tried to reproduce this behavior, and I've done a quite extensive
> set of tests on two different (quite different) machines, but so far I
> have not observed anything like that. The results are attached, along
> with the test scripts used.
>
> I wonder if this might be due to pg_ycsb using random_zipfian, which has
> somewhat annoying behavior for some parameters (as I've mentioned in a
> separate thread). But that should affect all the runs, not just some
> shared_buffers sizes.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>