Обсуждение: semget: No space left on device
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"
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"
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
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"