Thread: semget: No space left on device

semget: No space left on device

From
Keary Suska
Date:
I need to increase the max connections for my postgres installation but when
I do I get the dreaded "semget: No space left on device" error. Where can I
find information on the relationship between max connections and buffers and
shared memory/semaphores? I thought Bruce Momjian's performance tuning white
paper dealt with this, but the link to it is broken on the postgres.com web
site so I can't check it out.

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"


Re: semget: No space left on device

From
Keary Suska
Date:
on 5/9/03 3:09 PM, andrew@libertyrms.info purportedly said:

> On Fri, May 09, 2003 at 12:36:23PM -0600, Keary Suska wrote:
>> I do I get the dreaded "semget: No space left on device" error. Where can I
>> find information on the relationship between max connections and buffers and
>> shared memory/semaphores? I thought Bruce Momjian's performance tuning white
>
> I'd have a look in the manual itself:
>
> <http://www.us.postgresql.org/users-lounge/docs/7.3/postgres/runtime.html>
>

Thanks for the link. According to the info, I shouldn't have any problems. I
am shooting for 96 connections, using 192 buffers. My SHMMAX is 32mb, and
the calculations show that I need 2mb minimal for this, so even with
significant overhead I am fine.

Other values:
#define SEMMNI  128             /* ?  max # of semaphore identifiers */
#define SEMMSL  250              /* <= 512 max num of semaphores per id */
#define SEMMNS  (SEMMNI*SEMMSL) /* ? max # of semaphores in system */
#define SEMOPM  32              /* ~ 100 max num of ops per semop call */
#define SEMVMX  32767           /* semaphore maximum value */

/* unused */
#define SEMUME  SEMOPM          /* max num of undo entries per process */
#define SEMMNU  SEMMNS          /* num of undo structures system wide */
#define SEMAEM  (SEMVMX >> 1)   /* adjust on exit max value */
#define SEMMAP  SEMMNS          /* # of entries in semaphore map */
#define SEMUSZ  20              /* sizeof struct sem_undo */

Don't see any problem here.

# ipcs -l

------ Shared Memory Limits --------
max number of segments = 128
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 16777216
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767

------ Messages: Limits --------
max queues system wide = 128
max size of message (bytes) = 4056
default max size of queue (bytes) = 16384

(just for grins)

Maybe some other app is hogging:

# ipcs -u

------ Shared Memory Status --------
segments allocated 2
pages allocated 314
pages resident  165
pages swapped   0
Swap performance: 1446 attempts  72 successes

------ Semaphore Status --------
used arrays = 127
allocated semaphores = 159

------ Messages: Status --------
allocated queues = 0
used headers = 0
used space = 0 bytes

Doesn't seem like it.

Any ideas?

PG 7.1.3 on RH 6.2 Kernel 2.2.14


Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"


Re: semget: No space left on device

From
Tom Lane
Date:
Keary Suska <hierophant@pcisys.net> writes:
> I need to increase the max connections for my postgres installation but when
> I do I get the dreaded "semget: No space left on device" error. Where can I
> find information on the relationship between max connections and buffers and
> shared memory/semaphores?

You evidently need to raise SEMMNI: your setup is eating 127 of the 128
you have allowed.

It does seem odd that you have

------ Semaphore Status --------
used arrays = 127
allocated semaphores = 159

Postgres will normally allocate 17 semaphores per semaphore ID (a/k/a
semaphore array).  It looks to me like some not-Postgres application has
chewed up 125 semaphore IDs to represent only one actual semaphore apiece.
Postgres took two more for 17 apiece, then choked trying to get a third.

What else are you running ... and have you complained to them about
their profligacy with semaphore IDs?

            regards, tom lane


Re: semget: No space left on device

From
Keary Suska
Date:
on 5/9/03 9:25 PM, tgl@sss.pgh.pa.us purportedly said:

> You evidently need to raise SEMMNI: your setup is eating 127 of the 128
> you have allowed.
>
> It does seem odd that you have
>
> ------ Semaphore Status --------
> used arrays = 127
> allocated semaphores = 159
>
> Postgres will normally allocate 17 semaphores per semaphore ID (a/k/a
> semaphore array).  It looks to me like some not-Postgres application has
> chewed up 125 semaphore IDs to represent only one actual semaphore apiece.
> Postgres took two more for 17 apiece, then choked trying to get a third.
>
> What else are you running ... and have you complained to them about
> their profligacy with semaphore IDs?

D'oh! I missed that. It's Apache--naughty, naughty. May have a problem
cleaning up after itself, as it certainly doesn't need 125 arrays with only
one semaphore each!

I'll have to get them on that one...

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"