Re: Switch to unnamed POSIX semaphores as our preferred sema code?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Switch to unnamed POSIX semaphores as our preferred sema code?
Дата
Msg-id CA+TgmoZ-3UFcD-qBZevXLiw-_S3zm2xHgSy+Oa7-BCM+7g6_Sw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Switch to unnamed POSIX semaphores as our preferred sema code?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Switch to unnamed POSIX semaphores as our preferred sema code?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Switch to unnamed POSIX semaphores as our preferred sema code?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Oct 6, 2016 at 9:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Can anyone think of a test case that would stress semaphore operations
> more heavily, without being unrealistic?

I think it's going to be pretty hard to come up with a non-artificial
test case that has exhibits meaningful lwlock contention on an 8-core
system.  If you go back to 9.1, before we had fast-path locking, you
can do it, because the relation locks and vxid locks do cause
noticeable contention on the lock manager locks in that version.
Alternatively, you might try something like "pgbench -n -S -c $N -j
$N" with a scale factor that doesn't fit in shared buffers.  This
probably won't produce significant contention because there are 128
LWLocks and only 8 cores, but you could reduce the number of buffer
mapping LWLocks to, say, 4 and then you'd probably hit it fairly hard.

Alternatively, get a bigger box.  :-)

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: pgbench vs. wait events
Следующее
От: Christoph Berg
Дата:
Сообщение: Re: PostgreSQL - Weak DH group