Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

On Thu, 31 May 2012, Florian Pflug wrote:

> Wait, so performance *increased* by spreading the backends out over as
> many dies as possible, not by using as few as possible? That'd be
> exactly the opposite of what I'd have expected. (I'm assuming that cores
> on one die have ascending ids on linux. If you could post the contents
> of /proc/cpuinfo, we could verify that)

Yes, you are correct. And I also can confirm that the cpus in the cpuinfo
are ordered by "physical id" e.g. they go like
0 0 0 0 0 0 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3

I did a specific test with just 6 threads (== number of cores per cpu)
and ran it on a single phys cpu, it took ~ 12 seconds for each thread,
and when I tried to spread it across 4 cpus it took 7-9 seconds per
thread. But all these numbers are anyway significantly better then when I
didn't use taskset. Which probably means without it the processes were
jumping from core to core ? ...

>> Because still the slowdown was caused by locking. If there wouldn't be
>> locking there wouldn't be any problems (as demonstrated a while ago by
>> just cat'ting the files in multiple threads).
>
> Yup, we'll have to figure out a way to reduce the locking overhead. 9.2
> already scales much better to a large number of cores than previous
> versions did, but your test case shows that there's still room for
> improvement.

Yes, and unfortunately these scaling problems in read-only cpu
bound queries, where naively I wound't expect any.

Thanks,

Sergey

*****************************************************
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingley road, CB3 0HA, Cambridge, UK
Tel: +44-1223-337-551 Web: http://www.ast.cam.ac.uk/~koposov/