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
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 |