Re: [HACKERS] PostgreSQL and Solaris 7?

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: t-ishii(at)sra(dot)co(dot)jp, "Daryl W(dot) Dunbar" <daryl(at)www(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] PostgreSQL and Solaris 7?
Date: 1999-02-11 05:08:36
Message-ID: 199902110508.OAA01824@ext16.sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > I checked my Solaris box using sysdef and got:
>
> > 10 entries in semaphore map (SEMMAP)
> > 10 semaphore identifiers (SEMMNI)
> > 60 semaphores in system (SEMMNS)
> > 25 max semaphores per id (SEMMSL)
>
> These settings are far too small if you hope to go beyond a couple dozen
> Postgres backends. Postgres requires one semaphore per backend, which
> it (presently) allocates in groups of 16. Thus you cannot get past 48
> backends with these kernel settings --- starting the 49th backend requires
> allocating semaphores 49-64, but your system is set up to allow only 60
> semas total.
>
> (If your platform doesn't have a TEST_AND_SET implementation then
> several more semas are needed for spinlock emulation, but I assume
> that's not a problem on Solaris.)
>
> SEMMNI should also be bumped up, since you could not get past 10*16
> backends with it set at 10 --- and that's not allowing for anything
> else to be using semaphores! It'd be foolish not to leave at least
> a couple dozen semas and sema IDs free at Postgres' peak usage.
>
> I dunno what SEMMAP is (no such parameter in my kernel) but it
> probably needs to be at least as large as SEMMNI, possibly larger.

Ok. If I consider 64 backends, at least following settings would be
required from your suggestion:

64 entries in semaphore map (SEMMAP)
64 semaphore identifiers (SEMMNI)
64 semaphores in system (SEMMNS)
25 max semaphores per id (SEMMSL)

Is this correct?

> To run more than 64 backends you will also need to increase Postgres'
> internal MaxBackendId constant. Somewhere along here you are also
> likely to run into other kernel configuration limits, like the total
> number of processes, total processes for a single user, total number
> of open files, etc. These are all fixable but you don't want to
> reboot the system to install new values very often.
>
> We need a chapter in the installation guide that covers all this stuff
> in more detail... offhand I don't even know how many open files to
> allow per backend.

PostgreSQL seems to eat up file descriptor as many as possible. I
observe 30-40 or more files are opened by a backend. This is
definitelty a problem when thinking about large number of backends.

My solution is using limit or ulimit command to lower the number of
avaliable file descriptors when starting postmaster. The lowered
number must be 20 or greater, since PostgreSQL's "virtual file
descriptor" system reserves at least 20 open files per
backend(backend/storage/file/fd.c).
---
Tatsuo Ishii

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 1999-02-11 05:08:40 Re: [HACKERS] cannot cast bpchar and varchar
Previous Message Bruce Momjian 1999-02-11 03:07:57 Re: [HACKERS] interface libpq Makefile.in patch