Thread: Configure template change to use SysV Semaphors on darwin
Tom mentioned, > AFAIK the only platform where the POSIX sema code is really used is > Darwin (OS X), and it is not something I'd use there if I had a > choice. > The problem with it is that *every* semaphore corresponds to an open > file handle in the postmaster that has to be inherited by *every* > forked > child. So N backend slots cost you O(N^2) in kernel filehandles and > process fork overhead, plus if N is big you're taking a serious hit in > the number of disk files any one backend can have open. This problem > may be specific to Darwin's implementation of the POSIX spec, but it's > real enough there. If you trawl the archives you'll probably notice a > lack of people running big Postgres installations on Darwin, and > this is > why. I searched through the archives and I can't find a mention of why the posix_sema code was written for Darwin. I assume it is because before Darwin 6.0/Mac OS X 10.2 there was not kernel support for SysV semaphores. If this is in fact the case, I have a trivial patch to conditionally enable SysV semaphores based on the OS release: *** /Users/chrismarcellino/postgresql-8.2.2/src/template/darwin Fri Mar 10 20:38:40 2006 --- /Users/chrismarcellino/darwin Wed Feb 7 13:56:01 2007 *************** *** 4,8 **** # (Note: on OS X before 10.2, you might need -traditional-cpp instead) CC="$CC -no-cpp-precomp" ! # Select appropriate semaphore support ! USE_NAMED_POSIX_SEMAPHORES=1 --- 4,16 ---- # (Note: on OS X before 10.2, you might need -traditional-cpp instead) CC="$CC -no-cpp-precomp" ! # Select appropriate semaphore support. Darwin 6.0 (Mac OS X 10.2) and higher ! # support System V semaphores for better peformance. ! case $host_os in ! darwin[015].*) ! USE_NAMED_POSIX_SEMAPHORES=1 ! ;; ! *) ! USE_SYSV_SEMAPHORES=1 ! ;; ! esac Thanks, Chris Marcellino
Attachment
Chris Marcellino <cmarcellino@apple.com> writes:
> I searched through the archives and I can't find a mention of why the
> posix_sema code was written for Darwin.
Because Darwin didn't have anything else at the time.
> If this is in fact the case, I have a trivial patch to conditionally
> enable SysV semaphores based on the OS release:
Outta curiosity, can you measure any performance difference?
regards, tom lane
> Chris Marcellino <cmarcellino@apple.com> writes: >> I searched through the archives and I can't find a mention of why the >> posix_sema code was written for Darwin. If I understand Tom-san's English, POSIX sema has no problem on Linux (I'm afraid I'm misreading Tom-san's comment.) If so, can you also change the configure to use POSIX sema on Linux by default, after some performance benchmark (pgbench is enough)? If the users are freed from the tedious kernel IPC settings, the impression they have on PostgreSQL will improve, I think. IPC is the concept for software developers, not for software users. Currently, "IPC setting? What is that? Windows requires no such annoying task. Why do I have to do such a boring task for server software." "Oh, PostgreSQL requires users to set kernel parameters unlike other middleware. PostgreSQL is easy!" ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Chris Marcellino" <cmarcellino@apple.com> Cc: <pgsql-patches@postgresql.org> Sent: Thursday, February 08, 2007 9:54 AM Subject: Re: [PATCHES] Configure template change to use SysV Semaphors on darwin > Chris Marcellino <cmarcellino@apple.com> writes: >> I searched through the archives and I can't find a mention of why the >> posix_sema code was written for Darwin. > > Because Darwin didn't have anything else at the time. > >> If this is in fact the case, I have a trivial patch to conditionally >> enable SysV semaphores based on the OS release: > > Outta curiosity, can you measure any performance difference? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate >
Using pgbench, on 1 million records at each of 1, 10 and 100 concurrent users, I get the same results before and after the patch. I'm not sure if pgbench is the most appropriate benchmark for this though. The upside to using the SysV sema code on Darwin, to my understanding, is that the SysV semaphores use less memory (and no fd's). Darwin can support about 85k SysV semaphores system-wide, so it has no need for tuning in that respect, which is nice. Chris Marcellino On Feb 7, 2007, at 4:54 PM, Tom Lane wrote: > Chris Marcellino <cmarcellino@apple.com> writes: >> I searched through the archives and I can't find a mention of why the >> posix_sema code was written for Darwin. > > Because Darwin didn't have anything else at the time. > >> If this is in fact the case, I have a trivial patch to conditionally >> enable SysV semaphores based on the OS release: > > Outta curiosity, can you measure any performance difference? > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate
Chris Marcellino <cmarcellino@apple.com> writes:
> On Feb 7, 2007, at 4:54 PM, Tom Lane wrote:
>> Outta curiosity, can you measure any performance difference?
> Using pgbench, on 1 million records at each of 1, 10 and 100
> concurrent users, I get the same results before and after the patch.
> I'm not sure if pgbench is the most appropriate benchmark for this
> though.
Probably not. The issues about Darwin's POSIX-sema implementation
are (a) eating backend open-file slots, which won't matter when a
backend only touches a few different tables as pgbench does; and
(b) extra process-launch overhead, which won't matter to pgbench
because it's not launching new backends throughout the test.
I'm not sure that there is any standardized test that measures
these things, and yet it seems like it oughta matter in the real
world ...
regards, tom lane
From: "Tom Lane" <tgl@sss.pgh.pa.us> > Probably not. The issues about Darwin's POSIX-sema implementation > are (a) eating backend open-file slots, which won't matter when a > backend only touches a few different tables as pgbench does; and > (b) extra process-launch overhead, which won't matter to pgbench > because it's not launching new backends throughout the test. About (b), pgbench -C (upper case) can do. > I'm not sure that there is any standardized test that measures > these things, and yet it seems like it oughta matter in the real > world ... Does POSIX sema implementation use fds on popular platforms like Linux? Even if so, the users are freed from many kernel parameters such as semmni, semmns, semmsl, etc. What the users have to care about becomes only the number of file descriptors. Doesn't it seem to make settings easy?
Awhile back, Chris Marcellino <cmarcellino@apple.com> wrote:
> I searched through the archives and I can't find a mention of why the
> posix_sema code was written for Darwin.
> I assume it is because before Darwin 6.0/Mac OS X 10.2 there was not
> kernel support for SysV semaphores.
> If this is in fact the case, I have a trivial patch to conditionally
> enable SysV semaphores based on the OS release:
This seems to have slipped through the cracks --- apologies, but IIRC
core were a bit distracted with security issues right around then.
I've tried this patch on my Mac laptop, and while it seems to work as
advertised in terms of not eating a boatload of file descriptors,
I was disturbed to find that it seems consistently a couple percent
slower than the POSIX-sema code according to pgbench. I get numbers
like these:
SYSV POSIX
pgbench -c 10 -t 1000 104.4 tps 106.5 tps
pgbench -C -c 10 -t 1000 25.73 tps 26.07 tps
The numbers jump around a good deal from run to run, but it seemed that
the SYSV code was always a bit slower in two comparable runs.
Test conditions: PG CVS HEAD as of today, fully up-to-date OS X 10.4.9
running on a 1.33GHZ 12" Al Powerbook, all kernel and PG settings
default except for fsync off, pgbench initialized with -s 10. This of
course has nothing to do with real-world database performance, but I was
at least hoping to confirm that there wouldn't be any performance
penalty for switching to SYSV semas. Seems like there is. Comments?
regards, tom lane
I wrote:
> Awhile back, Chris Marcellino <cmarcellino@apple.com> wrote:
>> If this is in fact the case, I have a trivial patch to conditionally
>> enable SysV semaphores based on the OS release:
> I've tried this patch on my Mac laptop, and while it seems to work as
> advertised in terms of not eating a boatload of file descriptors,
> I was disturbed to find that it seems consistently a couple percent
> slower than the POSIX-sema code according to pgbench.
I rechecked this using PG CVS HEAD and can no longer reproduce a
slowdown --- in fact, the SYSV-sema code is marginally faster.
It's well within the noise level of pgbench, but anyway this seems
enough to allay my fears of a performance drop:
posix:
g42:~ tgl$ pgbench -c 10 -t 1000 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 107.051937 (including connections establishing)
tps = 107.207220 (excluding connections establishing)
sysv:
g42:~ tgl$ pgbench -c 10 -t 1000 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 107.565526 (including connections establishing)
tps = 107.730181 (excluding connections establishing)
I am not sure what changed since May, but one possibility is that
I just recently boosted the sysv shmem limit on my laptop. I think
the previous runs were probably taken with max_connections of 30
or so, whereas these numbers have max_connections = 100. That's
relevant since there are 3x more semaphores needed.
Anyway, getting rid of all the file descriptors for Posix semas
seems Clearly A Good Idea, so I'll go ahead and apply this patch.
Thanks for sending it in.
regards, tom lane