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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
