Re: Wait free LW_SHARED acquisition - v0.9

On 2014-10-11 06:49:54 +0530, Amit Kapila wrote:
> On Sat, Oct 11, 2014 at 6:29 AM, Andres Freund <andres@2ndquadrant.com>
> wrote:
> >
> > On 2014-10-11 06:18:11 +0530, Amit Kapila wrote:
> > I've run some short tests on hydra:
> >
> > scale 1000:
> >
> > base:
> > 4GB:
> > tps = 296273.004800 (including connections establishing)
> > tps = 296373.978100 (excluding connections establishing)
> >
> > 8GB:
> > tps = 338001.455970 (including connections establishing)
> > tps = 338177.439106 (excluding connections establishing)
> >
> > base + freelist:
> > 4GB:
> > tps = 297057.523528 (including connections establishing)
> > tps = 297156.987418 (excluding connections establishing)
> >
> > 8GB:
> > tps = 335123.867097 (including connections establishing)
> > tps = 335239.122472 (excluding connections establishing)
> >
> > base + LW_SHARED:
> > 4GB:
> > tps = 296262.164455 (including connections establishing)
> > tps = 296357.524819 (excluding connections establishing)
> > 8GB:
> > tps = 336988.744742 (including connections establishing)
> > tps = 337097.836395 (excluding connections establishing)
> >
> > base + LW_SHARED + freelist:
> > 4GB:
> > tps = 296887.981743 (including connections establishing)
> > tps = 296980.231853 (excluding connections establishing)
> >
> > 8GB:
> > tps = 345049.062898 (including connections establishing)
> > tps = 345161.947055 (excluding connections establishing)
> >
> > I've also run some preliminary tests using scale=3000 - and I couldn't
> > see a performance difference either.
> >
> > Note that all these are noticeably faster than your results.
> 
> What is the client count?

160, because that was the one you reported the biggest regression.

> Could you please post numbers you are getting for 3000 scale
> factor for client count 128 and 175?

Yes, although not tonight.... Also from hydra?

> > > Nothing specific, for performance tests where I have to take profiles
> > > I use below:
> > > ./configure --prefix=<installation_path>
> CFLAGS="-fno-omit-frame-pointer"
> > > make
> >
> > Hah. Doing so overwrites the CFLAGS configure normally sets. Check
> > # CFLAGS are selected so:
> > # If the user specifies something in the environment, that is used.
> > # else:  If the template file set something, that is used.
> > # else:  If coverage was enabled, don't set anything.
> > # else:  If the compiler is GCC, then we use -O2.
> > # else:  If the compiler is something else, then we use -O, unless
> debugging.
> >
> > so, if you do like above, you're compiling without optimizations... So,
> > include at least -O2 as well.
> 
> Hmm. okay, but is this required when we do actual performance
> tests, because for that currently I don't use CFLAGS.

I'm not sure what you mean? You need to include -O2 in CFLAGS whenever
you override it. Your profile was clearly without inlining... And since
your general performance numbers are a fair bit lower than what I see
with, hopefully, the same code on the same machine...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services