Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions - Mailing list pgsql-hackers

Hi Mengxing

Please read my comments :


On 3/14/17 17:34, Mengxing Liu wrote:
> 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?
The configuration is really cool, for the SSD, is it SATA interface?
NVMe interface, or is PCIe Flash? different SSD interface had different
performance characters.

for the NUMA, because the affinity issue will impact PostgreSQL
performance. so, Please disabled it if possible
>
>>> 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 benchmark tool, TPC-E is the latest spec, could use it to stress PG
for OLTP application/mode.
but for PostgreSQL, pgbench is developed by community, and used to
benchmark PG performance.
however, you could use any you like, it depends on your situation. ^_^ 
>
> For me, the challenge is profiling the execution. Is there any tools in PostgreSQL to analysis where is the CPU
cyclesconsumed?
 
> Or I have to instrument and time by myself?
in Solaris system, there is a strong probe system available, it named
Dtrace, you might use it to profiling
but for how to use it, I think you need to consult illumos(a fork from
Solaris/OpenSolaris), IRC channel is #illumos on freechat.net, (but I
think there is Dtrace expert in this mail list, you could write other
thread to ask)
>
>
> Regards.
>
> --
> Mengxing Liu
>
>
>
>
>
>
>
>
>
>