RE: [HACKERS] PostgreSQL and Solaris 7?

In order to increase the number of semaphores, I added the following
entries to /etc/system and rebooted:
*
* Increase the total number of Semaphores per user and system
set semsys:seminfo_semmap=128
set semsys:seminfo_semmni=128
set semsys:seminfo_semmns=8192
set semsys:seminfo_semmnu=8192
set semsys:seminfo_semmsl=64
set semsys:seminfo_semopm=32
set semsys:seminfo_semume=32

These values are considerably larger than the defaults but more in
line with the Linux defaults. Please note I have 512MB of memory on
my Sparc, so I was not concerned about allocating too much table
space.

Thanks all for your help, this seems to have solved my problem.

DwD

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Wednesday, February 10, 1999 10:01 AM
> To: t-ishii(at)sra(dot)co(dot)jp
> Cc: Daryl W. Dunbar; pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: [HACKERS] PostgreSQL and Solaris 7?
>
>
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> >>> Increasing # of semaphores should solve the problem,
> I guess. I'm
> >>> going to try that as soon as I find the way to
> increase semaphores.
>
> Right --- the messages Daryl is seeing indicate he's
> running out of
> semaphores or semaphore IDs, not file space. (Someone
> was too lazy
> to create a separate kernel errno for out-of-semaphores.)
>
> : IpcSemaphoreCreate: semget failed (No space left on device)
> ^^^^^^^^^^^^^
>
> My guess is that the "WaitOnLock" and "stuck spinlock"
> complaints are
> artifacts of not being able to recover from the out-of-semaphores
> condition. I hope to make this a little more robust in
> time for 6.5.
>
> > 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.
>
> 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.
>
> regards, tom lane
>