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

From: "Mengxing Liu" <liu-mx15(at)mails(dot)tsinghua(dot)edu(dot)cn>
To: "Kevin Grittner" <kgrittn(at)gmail(dot)com>
Cc: DEV_OPS <devops(at)ww-it(dot)cn>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
Date: 2017-03-15 16:35:34
Message-ID: 61692e1c.2172a.15ad2d31afc.Coremail.liu-mx15@mails.tsinghua.edu.cn
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Messages-----
> From: "Kevin Grittner" <kgrittn(at)gmail(dot)com>
> Sent Time: 2017-03-15 23:20:07 (Wednesday)
> To: DEV_OPS <devops(at)ww-it(dot)cn>
> Cc: "Mengxing Liu" <liu-mx15(at)mails(dot)tsinghua(dot)edu(dot)cn>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
> Subject: Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
>
> On Tue, Mar 14, 2017 at 3:45 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> >> On 3/14/17 17:34, Mengxing Liu wrote:
> >>> There are several alternative benchmarks. Tony suggested that we
> >>> should use TPC-E and TPC-DS.
> >
> > More benchmarks is better, all other things being equal. Keep in
> > mind that good benchmarking practice with PostgreSQL generally
> > requires a lot of setup time (so that we're starting from the exact
> > same conditions for every run), a lot of run time (so that the
> > effects of vacuuming, bloat, and page splitting all comes into play,
> > like it would in the real world), and a lot of repetitions of each
> > run (to account for variation). In particular, on a NUMA machine it
> > is not at all unusual to see bifurcated
>
> Sorry I didn't finish that sentence.
>
> On a NUMA machine It is not at all unusual to see bifurcated results
> -- with each run coming in very close to one number or a second
> number, often at about a 50/50 rate, with no numbers falling
> anywhere else. This seems to be based on where the processes and
> memory allocations happen to land.
>

Do you mean that for a NUMA machine, there usually exists two different results of its performance?
Just two? Neither three nor four?

Anyway, firstly, I think I should get familiar with PostgreSQL and tools you recommended to me at first.
Then I will try to have a better comprehension about it, to make our discussion more efficient.

Recently, I am busy preparing for the presentation at ASPLOS'17 and other lab works.
But I promise I can finish all preparation works before May. Here is my working plan:
At first, I will compile and install PostgreSQL by myself and try the profile tools (perf or oprofile).
Then I will run one or two benchmarks using different config, where I may need your help to ensure that my tests are close to the practical situation.

PS: Disable NUMA in BIOS means that CPU can use its own memory controller when accessing local memory to reduce hops.
On the contrary, "enable" means UMA. Therefore, I think Tony is right, we should disable this setting.
I got the information from here. http://frankdenneman.nl/2010/12/28/node-interleaving-enable-or-disable/

Regards.

--
Mengxing Liu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2017-03-15 16:35:59 Re: Parallel Bitmap scans a bit broken
Previous Message Peter Eisentraut 2017-03-15 16:33:23 Re: ICU integration