Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

I send this email to Tony, too. Because he promised to help me with testing and benchmarking.

>
> >> The worst problems have been
> >> seen with 32 or more cores on 4 or more sockets with a large number
> >> of active connections. I don't know whether you have access to a
> >> machine capable of putting this kind of stress on it (perhaps at
> >> your university?), but if not, the community has access to various
> >> resources we should be able to schedule time on.
> >
> > There is a NUMA machine ( 120 cores, 8 sockets) in my lab.
>
> Fantastic! Can you say a bit more about the architecture and OS?
>

Intel(R) Xeon(R) CPU at 2.3GHz, with 1TB physical DRAM and 1.5 TB SSD, running Ubuntu 14.04, Kernel 3.19.
I guess NUMA is disabled in BIOS, but I will check that.
However, there is only one NIC, so network could be the bottleneck if we use too many cores?

> > I think it's enough to put this kind of stress.
>
> The researchers who saw this bottleneck reported that performance
> started to dip at 16 cores and the problem was very noticeable at 32
> cores. A stress test with 120 cores on 8 sockets will be great!
>
> I think perhaps the first milestone on the project should be to
> develop a set of benchmarks we want to compare to at the end. That
> would need to include a stress test that clearly shows the problem
> we're trying to solve, along with some cases involving 1 or two
> connections -- just to make sure we don't harm performance for
> low-contention situations.
>

Thank for your advice! It's really helpful for my proposal.

There are several alternative benchmarks. Tony suggested that we should use TPC-E and TPC-DS.
Personally, I am more familiar with TPC-C. And pgbench seems only have TPC-B built-in benchmark.
Well, I think we can easily find the implementations of these benchmarks for PostgreSQL.
The paper you recommended to me used a special benchmark defined by themselves. But it is quite simple and easy to implement.

For me, the challenge is profiling the execution. Is there any tools in PostgreSQL to analysis where is the CPU cycles consumed?
Or I have to instrument and time by myself?

Regards.

--
Mengxing Liu