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/