locking/performance, Solaris performance discovery

On Mon, 6 Oct 2003, Andrew Sullivan wrote:

> There's plenty of academic work which purports to show that LRU is
> far from the best choice. Just in principle, it seems obvious that a
> single-case seqscan-type operation (such as vacuum does) is a good
> way to lose your cache for no real gain.
>

Logically bypassing caches for a seq scan also makes sense.

> Interestingly, we're contemplating ditching Solaris because of the
> terrible reliability we're getting from the hardware.
>

The reason ops likes solaris / sun is twofold. 1. we have a pile of big
sun machines around. 2. Solaris / Sun is quite a bit more graceful in the
egvent of a hardware failure. We've burned out our fair share of cpu's
etc and solaris has been rather graceful about it.

I've started profiling and running tests... currently it is leaning
towards the sysv semaphores. I see in src/backend/port/ that pg_sema.c is
linked to the sysv implementation. So what I did was create a
semaphore set, and then fired off 5 copies of a program that attaches
to that semaphore and then locks/unlocks it 1M times.

2xP2-450, Linux 2.4.18: 1 process: 221680 / sec, 5 process: 98039 / sec
4xUltraSparc II-400Mhz, Solaris 2.6: 1 proc: 142857 / sec, 5 process:
23809

So I'm guessing that is where a LOT of the suck is coming from.

What I plan to do next is looking to see if there are other interprocess
locking mechanisms on solaris (perhaps pthread_mutex with that
inter-process flag or something) to see if I can get those numbers a
little closer.

--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.jefftrout.com/
http://www.stuarthamm.net/