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?
Re: Switch to unnamed POSIX semaphores as our preferred sema code? |
Список | 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 по дате отправления: