Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x - Mailing list pgsql-hackers
From | Roberth Andersson |
---|---|
Subject | Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x |
Date | |
Msg-id | 4.1.19990731183041.009ca810@jump-gate.com Whole thread Raw |
List | pgsql-hackers |
At 11:55 1999-07-31 -0400, you wrote: >Roberth Andersson <roberth@jump-gate.com> writes: >> BUT when I wrote "postmaster -i" I got a big >> problem which I have never got ever before and I don't know why. Here is >> the error message from postmaster -> > >> IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, >> size=1063936, permission=600 >> FATAL 1: ShmemCreate: cannot create region > >The kernel error message ("Invalid argument", here) is often very >unhelpful when dealing with shared memory and semaphore operations :-( >I will bet that the real problem is that your kernel is configured >not to allow shared mem regions bigger than 1 megabyte --- but could >it say "Request too big", or some such? Nooo... >Postgres 6.5 defaults to wanting a shmem region just over a meg, whereas >6.4 was just under IIRC, so this problem will bite anyone who has the >fairly common kernel parameter setting SHMEMMAX = 1meg. >If that's the problem, you can either reconfigure your kernel with a >larger SHMEMMAX setting, or start Postgres with smaller-than-default >limits on number of buffers and backends. I'd try -N 16 for starters. >Another possibility is that you are running into a kernel limit on the >total amount of shared memory, not the size of this individual chunk. >You say: Thanks Tom Is it possible to find how big it is right now without touching the kernel source codes ? I tried to search also for SHMEMMAX in the source codes, but found nothing. I am going to try to start up Postgres later today with your suggested parameter -N 16 and see whats happends. >> This is what I get when I write ipcs -> >> Message Queues: >> T ID KEY MODE OWNER GROUP > >> Shared Memory: >> T ID KEY MODE OWNER GROUP >> m 196608 5432210 --rwa------ postgres user >> m 196609 5432201 --rw------- postgres user >> m 983042 5432207 --rw------- postgres user >> m 1376259 5432010 --rwa------ postgres postgres >> m 131076 5432001 --rw------- postgres user >> m 786437 5432007 --rw------- postgres postgres > >> Semaphores: >> T ID KEY MODE OWNER GROUP > >If you do not have a postmaster running then those postgres-owned shared >memory segments should not be there; they must be left over from some >old run where the postmaster crashed without releasing 'em :-(. They >could be causing the kernel to decide it's given out too much shared >memory. Use ipcclean to get rid of them. I tried to do that and it worked just fine the first time, and after that I wrote "ipcs" to get a statistical if it really was cleaned or not, but I got this -> Message Queues: T ID KEY MODE OWNER GROUP Shared Memory: T ID KEY MODE OWNER GROUP m 1376259 0 --rwa------ postgres postgres m 131076 0 --rw------- postgres user m 786437 0 --rw------- postgres postgres Semaphores: T ID KEY MODE OWNER GROUP Now I tried to use "ipcclean" once again, and I am always getting these errors -> ipcrm: shmid(1376259): : Invalid argument ipcrm: shmid(131076): : Invalid argument ipcrm: shmid(786437): : Invalid argument I have no idea why, except maybe this could be something that is left over since old and now the system doesn't know how to remove this Postgres stuff. If anyone have any clue about what I can do, please let me know, I would appreciate it a lot. Sincerely
pgsql-hackers by date: