Re: MIT benchmarks pgsql multicore (up to 48)performance

On Mon, Oct 4, 2010 at 10:44 AM, Hakan Kocaman <hkocam(at)googlemail(dot)com> wrote:
> for whom it may concern:
> http://pdos.csail.mit.edu/mosbench/
> They tested with 8.3.9, i wonder what results 9.0 would give.
> Best regards and keep up the good work
> Hakan

Here's the most relevant bit to us:

--
The “Stock” line in Figures 7 and 8 shows that Post- greSQL has poor
scalability on the stock kernel. The first bottleneck we encountered,
which caused the read/write workload’s total throughput to peak at
only 28 cores, was due to PostgreSQL’s design. PostgreSQL implements
row- and table-level locks atop user-level mutexes; as a result, even
a non-conflicting row- or table-level lock acquisition requires
exclusively locking one of only 16 global mutexes. This leads to
unnecessary contention for non-conflicting acquisitions of the same
lock—as seen in the read/write workload—and to false contention
between unrelated locks that hash to the same exclusive mutex. We
address this problem by rewriting PostgreSQL’s row- and table-level
lock manager and its mutexes to be lock-free in the uncontended case,
and by increasing the number of mutexes from 16 to 1024.
--

I believe the "one of only 16 global mutexes" comment is referring to
NUM_LOCK_PARTITIONS (there's also NUM_BUFFER_PARTITIONS, but that
wouldn't be relevant for row and table-level locks). Increasing that
from 16 to 1024 wouldn't be free and it's not clear to me that they've
done anything to work around the downsides of such a change. Perhaps
it's worthwhile anyway on a 48-core machine! The use of lock-free
techniques seems quite interesting; unfortunately, I know next to
nothing about the topic and this paper doesn't provide much of an
introduction. Anyone have a reference to a good introductory paper on
the topic?

The other sort of interesting thing that they mention is that
apparently I/O between shared buffers and the underlying data files
causes a lot of kernel contention due to inode locks induced by
lseek(). There's nothing much we can do about that within PG but
surely it would be nice if it got fixed upstream.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company