Robert Haas <robertmhaas@gmail.com> writes:
> 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, get a bigger box. :-)
Well, I did both of the above. I tried 9.1 on "hydra", that 60-processor
POWER7 box, and cranked the parallelism up to ridiculous levels:
pgbench -S -j 250 -c 250 -M prepared -T 60 bench
Median of 3 runs with sysv semaphores:
number of transactions actually processed: 1554570
tps = 25875.432836 (including connections establishing)
tps = 25894.938187 (excluding connections establishing)
Ditto, for unnamed POSIX semaphores:
number of transactions actually processed: 1726696
tps = 28742.486104 (including connections establishing)
tps = 28765.963071 (excluding connections establishing)
That's about a 10% win for POSIX semaphores. Now, at saner loads,
I couldn't see much of any difference between the two semaphore APIs.
So I'm still of the opinion that there's not likely to be any meaningful
performance difference in practice, at least not on reasonably recent
Linux machines. But this does indicate that if there is any difference,
it will probably favor switching.
regards, tom lane
