dbTalk Databases Forums  

shared memory after server kill

comp.databases.postgresql.novice comp.databases.postgresql.novice


Discuss shared memory after server kill in the comp.databases.postgresql.novice forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Sean Davis
 
Posts: n/a

Default shared memory after server kill - 08-05-2004 , 05:34 AM






I have a problem that I can't understand.

I am using macosx, pg 7.4.3. I had a server running and working. I
tried to bring the server down with 'pg_ctl stop', which failed (server
running on localhost). I then (timidly) killed the postmaster process.

When I tried to bring the server back up, I got an error similar to:

FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=1, size=1081344, 03600).
HINT: This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space. To reduce the
request size (currently 1081344 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 50) and/or its max_connections
parameter (currently 10).
The PostgreSQL documentation contains more information about
shared memory configuration.

I have 4 Gb of memory, with approximately 2.6 Gb available (via top)
and a vast swap. What is going on?

Thanks,
Sean


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match


Reply With Quote
  #2  
Old   
Sean Davis
 
Posts: n/a

Default Re: shared memory after server kill - 08-05-2004 , 05:47 AM






I forgot to mention--I then cleaned the installation (removed the
installed root directory), reinstalled, did initdb and got the same
result with the initdb call.

Sean

On Aug 5, 2004, at 6:34 AM, Sean Davis wrote:

Quote:
I have a problem that I can't understand.

I am using macosx, pg 7.4.3. I had a server running and working. I
tried to bring the server down with 'pg_ctl stop', which failed
(server running on localhost). I then (timidly) killed the postmaster
process.

When I tried to bring the server back up, I got an error similar to:

FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=1, size=1081344, 03600).
HINT: This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space. To reduce the
request size (currently 1081344 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 50) and/or its max_connections
parameter (currently 10).
The PostgreSQL documentation contains more information about
shared memory configuration.

I have 4 Gb of memory, with approximately 2.6 Gb available (via top)
and a vast swap. What is going on?

Thanks,
Sean


---------------------------(end of
broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if
your
joining column's datatypes do not match

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)



Reply With Quote
  #3  
Old   
Oliver Fromme
 
Posts: n/a

Default Re: shared memory after server kill - 08-05-2004 , 06:06 AM




Sean Davis wrote:
Quote:
I am using macosx, pg 7.4.3. I had a server running and working. I
tried to bring the server down with 'pg_ctl stop', which failed (server
running on localhost). I then (timidly) killed the postmaster process.

When I tried to bring the server back up, I got an error similar to:

FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=1, size=1081344, 03600).
[...]
I have 4 Gb of memory, with approximately 2.6 Gb available (via top)
and a vast swap. What is going on?
When you kill the postmaster process forcibly, it doesn't
release the shared memory segments that it had allocated.

Use the "ipcs" command to list all currently allocated
shared memory segments, and use "ipcrm" to remove them.
I've once written a small shell script which basically
does it (I've only tested it on FreeBSD, but Mac OS X
should be similar enough):

#!/bin/sh -
ipcs | awk '($1=="m"){print $2}' | xargs -n 1 -t ipcrm -m

Of course, you can also solve the problem the Windows way
(i.e. reboot). ;-)

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

With Perl you can manipulate text, interact with programs, talk over
networks, drive Web pages, perform arbitrary precision arithmetic,
and write programs that look like Snoopy swearing.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)



Reply With Quote
  #4  
Old   
Tom Lane
 
Posts: n/a

Default Re: shared memory after server kill - 08-05-2004 , 09:17 AM



Oliver Fromme <olli (AT) lurza (DOT) secnetix.de> writes:
Quote:
When you kill the postmaster process forcibly, it doesn't
release the shared memory segments that it had allocated.

Use the "ipcs" command to list all currently allocated
shared memory segments, and use "ipcrm" to remove them.
For some benighted reason, OS X doesn't provide either of those commands
(last I looked anyway). AFAIK the only way to get rid of an unreleased
shmem segment in OS X is to reboot; there is no manual access to the
shared memory status.

Combine this problem with the fact that OS X's default limit on shmem
size is very small (not enough to allow two reasonable-sized shmem
segments), and you end up with the conclusion that kill -9'ing the
postmaster is an even worse idea on OS X than it is on other systems.
Next time use "kill -QUIT" if you want an emergency postmaster shutdown.
Or try "pg_ctl stop -m fast".

(But I think the real beginner mistake was to try to solve a problem by
killing the postmaster, rather than whichever child process was wedged.
The postmaster process is almost never the direct source of a user-visible
problem.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.