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

Hi Mengxing,

Mengxing Liu wrote:
> Hi, Alvaro and Kevin. I'm Mengxing.
>
> This is a “synchronization” email to tell you what I've done and my next plan. I'm looking forward to your advice.

Welcome!

> According to my proposal, I want to prepare the experimental environment during the community bonding period.
>
> As this is the first time I discuss with Alvaro, here I will introduce the environment again.
>
> My lab have a Lenovo System x3950 X6 machine.
>
> https://www.lenovo.com/images/products/system-x/pdfs/datasheets/x3950_x6_ds.pdf
>
> More specifically, there are 8 sockets, each has 15 Intel(R) Xeon(R) CPU E7-8870 v2 @ 2.30GHz.
>
> Thus we have 120 cores in total. The storage is a 1 TB SSD, with SAS interface, 500MB write bandwidth.

OK, having a single disk and 120 CPU cores sounds unbalanced.

> Because we have too many cores, SSD becomes the bottleneck. In my test, pgbench can scale to 36 connections. ( 18 KTPS throughput). CPU utilization is smaller than 30%.
>
> Therefore:
>
> 1. Is there anything wrong in my tuning parameters？For example, should I close "fsync"? Because we don't care recovery here.

While it's true that we don't care about recovery, I'm not sure that
benchmark results would still be valid with fsync=off. I would try
synchronous_commit=off instead, and perhaps also enlarge wal_buffers.
What do you have shared_buffers set to?

> 2. Can we use just two sockets (30 physical cores) to run database server? Then the CPU can be the bottleneck so that it shows the problem we try to solve.

Sure -- it's not a Postgres option, but an operating system option:
you'd set the "maxcpus" parameter in GRUB when booting Linux.
Alternatively, you could use "numactl" to bind the postgres server to a
subset of CPUs. (And you could put pgbench on a different CPU set).

> > What method of communication will be used among the mentors and with Mengxing.
>
> What method do you prefer?

Mailing list is fine.

> > Frequency of status updates (must be at least once a week and more often is encouraged).
>
> How about reporting my status once a week?

Once a week sounds good to me.

> > What steps will be taken next during the community bonding period.
>
> As I wrote in the proposal, I want to establish the environment and read the related source code. Do you have any suggestions for me?

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services