Thread: Semaphores was: Increasing the number of semaphores on FreeBSD 4. 1 (clarification)

Whoa! Shit! I'm working on a system which probably will use ALOT of
semaphores and mutexes. Is this the limits, <1000? I was hoping for
millions. I have asked around but no-one I have asked seems to know the
answer.

I'm using pthreads on Linux right now but will probably use HP-UX, AIX,
True64 or Solaris when going live.

How many semaphores and mutexes can one have, both in theory and
practically?

/Roger

-----Original Message-----
From: Alfred Perlstein [mailto:bright@wintelcom.net]
Sent: Friday, November 10, 2000 5:56 AM
To: Philip Hallstrom
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Increasing the number of semaphores on FreeBSD
4.1 (clarification)


* Philip Hallstrom <philip@adhesivemedia.com> [001109 20:37] wrote:
>
> > * Philip Hallstrom <philip@adhesivemedia.com> [001109 19:12] wrote:
> > > Hi -
> > >     I recently tried to start postmaster (7.0.2) with -B 128 -N 64 and
> > > got the "semget failed" error.  Looking in the faq[1] it says I need
to
> > > increase the amount allowed in the kernel.  It tells me what I need to
do,
> > > but my question is what values should I set them to?  Is there any way
to
> > > figure it out based on load, etc?  Also, are there detrimental effects
to
> > > setting them too high?
> >
> > What OS are you using?
>
> FreeBSD 4.1
>
> > > [1]http://postgresql.readysetnet.com/docs/faq-bsdi
> >
> > If it's FreeBSD we've documented the tunables here:
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/NOTES?rev=1.857
> >
> > The docs will probably also help if you're using BSD/os.
> >
> > Also you don't want to "go nuts" with raising these values, they
> > can cause the kernel to allocate too much memory for these structures
> > and cause problems booting or running your system.
>
> Yeah, that's what I've seen... I guess I was wondering if there were any
> guidelines to raising them..  I mean should I up the defaults by 10?  Or
> up them by a percentage (to keep the relationship), etc...

here's what I use:

options         SHMMAXPGS=512000
options         SHMSEG=128
options         SEMMNI=40       #       /* # of semaphore identifiers */
options         SEMMNS=240      #       /* # of semaphores in system */
options         SEMUME=40       #       /* max # of undo entries per process
*/
options         SEMMNU=120      #       /* # of undo structures in system */

I have a gig of RAM though.

--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

> * Philip Hallstrom <philip@adhesivemedia.com> [001109 20:37] wrote:
> >
> > Yeah, that's what I've seen... I guess I was wondering if there were any
> > guidelines to raising them..  I mean should I up the defaults by 10?  Or
> > up them by a percentage (to keep the relationship), etc...
>
> here's what I use:
>
> options         SHMMAXPGS=512000
> options         SHMSEG=128
> options         SEMMNI=40       #       /* # of semaphore identifiers */
> options         SEMMNS=240      #       /* # of semaphores in system */
> options         SEMUME=40       #       /* max # of undo entries per process
> */
> options         SEMMNU=120      #       /* # of undo structures in system */
>
> I have a gig of RAM though.
>

* Roger Wernersson <roger.wernersson@mindark.com> [001110 03:00] wrote:
> Whoa! Shit! I'm working on a system which probably will use ALOT of
> semaphores and mutexes. Is this the limits, <1000? I was hoping for
> millions. I have asked around but no-one I have asked seems to know the
> answer.
>
> I'm using pthreads on Linux right now but will probably use HP-UX, AIX,
> True64 or Solaris when going live.
>
> How many semaphores and mutexes can one have, both in theory and
> practically?

Please don't drop me from the CC' list if you expect me to reply.

As far as system tunables, well, it depends on how much memory you
have available and what the OS is capable of.  I just didn't want
Phill to go nuts and try values that were 1000x some reasonable
figure.  In FreeBSD a lot of it is dynamically allocated so there
shouldn't have been a problem in configuring that many segments/semaphores.

The problem is when you actually use them and you run out of kernel
memory, this is _BAD_ and why there are limits in place on most
systems.

Oh, and I'd take a shot at use FreeBSD in production, we do, Yahoo
does and it kicks butt. :)

bye,
-Alfred

Hi!

I'm developing a SQL proxy and I would like to implement the server
protocol used by Postgres, so the proxy may act like a PostgreSQL server
towards the clients.

I have read the nice and clean documentation of the protocol on
http://www.postgresql.org/docs/programmer/protocol.htm, but instead of
reimplementating the protocol I would like to reuse the current
implementation.

As far as I can tell from the protocol specification and the description
of how PostgreSQL processes a query (src/tools/backend/index.html) it is
implemented in or around src/backend/postmaster/postmaster.c and
src/backend/tcop/postgres.c - but I still have a bit of problems finding
my way around the sourcecode.

Could anyone direct me to the specific parts of the sourcecode dealing
with the frontend/backend protocol?

--
Bye, Peter Korsgaard

Peter Korsgaard <jacmet@control.auc.dk> writes:
> I'm developing a SQL proxy and I would like to implement the server
> protocol used by Postgres, so the proxy may act like a PostgreSQL server
> towards the clients.

> I have read the nice and clean documentation of the protocol on
> http://www.postgresql.org/docs/programmer/protocol.htm, but instead of
> reimplementating the protocol I would like to reuse the current
> implementation.

I think you'd be better off coding from scratch.  The backend is built
on the model that it's in control and it can send off messages or bits
of messages whenever it feels like.  It's going to be very difficult to
adapt that code to a multi-client proxy server, even assuming you could
easily extract just the code that does communication --- but the forest
is rather thickly clustered around those trees ;-)

> As far as I can tell from the protocol specification and the description
> of how PostgreSQL processes a query (src/tools/backend/index.html) it is
> implemented in or around src/backend/postmaster/postmaster.c and
> src/backend/tcop/postgres.c - but I still have a bit of problems finding
> my way around the sourcecode.

postmaster.c and postgres.c are the outer loops, but they don't actually
do much of the message-slinging.  The low-level I/O code is in
backend/libpq.  The rest of the message processing is, um, hither and
yon.

            regards, tom lane

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

Tom> Peter Korsgaard <jacmet@control.auc.dk> writes:
>> I'm developing a SQL proxy and I would like to implement the server
>> protocol used by Postgres, so the proxy may act like a PostgreSQL server
>> towards the clients.

>> I have read the nice and clean documentation of the protocol on
>> http://www.postgresql.org/docs/programmer/protocol.htm, but instead of
>> reimplementating the protocol I would like to reuse the current
>> implementation.

Tom> I think you'd be better off coding from scratch.  The backend is built
Tom> on the model that it's in control and it can send off messages or bits
Tom> of messages whenever it feels like.  It's going to be very difficult to
Tom> adapt that code to a multi-client proxy server, even assuming you could
Tom> easily extract just the code that does communication --- but the forest
Tom> is rather thickly clustered around those trees ;-)

>> As far as I can tell from the protocol specification and the description
>> of how PostgreSQL processes a query (src/tools/backend/index.html) it is
>> implemented in or around src/backend/postmaster/postmaster.c and
>> src/backend/tcop/postgres.c - but I still have a bit of problems finding
>> my way around the sourcecode.

Tom> postmaster.c and postgres.c are the outer loops, but they don't actually
Tom> do much of the message-slinging.  The low-level I/O code is in
Tom> backend/libpq.  The rest of the message processing is, um, hither and
Tom> yon.

As a related note (I'm working with Peter on this thing) we asked the
MySQL guys about this. It seems they have all ready prepared MySQL for
distribution in that they have implemented a structure like "LOAD
TABLE FROM MASTER" which would then sync the table from a master to a
slave. Has PostgreSQL anything similar, or do we have to do it
ourselv? (I think, any help is appriciated, since we are seriously
running out of time ,-)).

Regards,

Lars Chr. Hausmann

Lars Chr. Hausmann writes:

> As a related note (I'm working with Peter on this thing) we asked the
> MySQL guys about this. It seems they have all ready prepared MySQL for
> distribution in that they have implemented a structure like "LOAD
> TABLE FROM MASTER" which would then sync the table from a master to a
> slave.

Are they locking down both the master and the slave table while doing
this?

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Hi!

I got the startup part of the serverprotocol implemented according to the
documentation at http://www.postgresql.org/docs/programmer/protocol.htm,
but there seems to be something missing in the specification.
After I send the ReadyForQuery packet I recieve a Query packet containing
"select getdatabaseencoding()", which I cannot find information about
anywhere. A search on the postgresql website only gives a reference to a
bugfix regarding unicode characters and varchars, but I guess it's
something about the character encoding used.

What am I supposed to return in response to this select?

--
Bye, Peter Korsgaard

Peter Korsgaard <jacmet@control.auc.dk> writes:
> After I send the ReadyForQuery packet I recieve a Query packet containing
> "select getdatabaseencoding()", which I cannot find information about
> anywhere.

It's just an SQL function in the backend.

> What am I supposed to return in response to this select?

You're supposed to send it to the backend for execution and pass back
the resulting output.

You'll find that libpq (and psql even more so) issue a number of queries
all by themselves after connection startup; just because you don't think
you've done anything doesn't mean that the backend hasn't cycled through
several queries ...

            regards, tom lane

On Mon, 20 Nov 2000, Tom Lane wrote:

> > After I send the ReadyForQuery packet I recieve a Query packet containing
> > "select getdatabaseencoding()", which I cannot find information about
> > anywhere.
>
> It's just an SQL function in the backend.

Ok. I accidentially misspelled it in pgsql and it gave me an error. Stupid
me assumed it wasn't a normal function and some part of the startup
protocol.

Thanks!

--
Bye, Peter Korsgaard

Hi!

I'm still working on the SQL proxy, and I'm having some questions
regarding the insert/update/delete queries.

As far as I can tell there is no way of differenciating between
successfull insert/update/delete queries in libpq, they all return
PGRES_COMMAND_OK (PQresultStatus). This is unfortunate considering that I
have to send a different reply to the client for each of the 3 types of
queries (INSERT oid rows, UPDATE rows or DELETE rows). Is there any other
way than examinating the query string that I forward to the real database
server while using libpq or do I have to forget about libpq and use raw
sockets?

--
Bye, Peter Korsgaard