Re: MIT benchmarks pgsql multicore (up to 48)performance
От | Robert Haas |
---|---|
Тема | Re: MIT benchmarks pgsql multicore (up to 48)performance |
Дата | |
Msg-id | AANLkTi=33M9adSmdBQuYBeeaWX-Z=c9+DcUp8oRRG_Ru@mail.gmail.com обсуждение исходный текст |
Ответ на | MIT benchmarks pgsql multicore (up to 48)performance (Hakan Kocaman <hkocam@googlemail.com>) |
Ответы |
Re: MIT benchmarks pgsql multicore (up to 48)performance
(Michael Glaesemann <grzm@seespotcode.net>)
Re: MIT benchmarks pgsql multicore (up to 48)performance (Greg Stark <gsstark@mit.edu>) Re: MIT benchmarks pgsql multicore (up to 48)performance (Dan Ports <drkp@csail.mit.edu>) |
Список | pgsql-hackers |
On Mon, Oct 4, 2010 at 10:44 AM, Hakan Kocaman <hkocam@googlemail.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
В списке pgsql-hackers по дате отправления: