> -----Original Messages-----
> From: "Kevin Grittner" <kgrittn@gmail.com>
> Sent Time: 2017-03-15 23:20:07 (Wednesday)
> To: DEV_OPS <devops@ww-it.cn>
> Cc: "Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.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@gmail.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
closeto 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
