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 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.vondra@2ndquadrant.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
