Skip site navigation (1) Skip section navigation (2)

Re: shared memory leak in 7.0.2?

From: Pierre Padovani <ppadovan(at)tivoli(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pierre(at)kahuna(dot)versions(dot)com, pgsql-sql(at)postgresql(dot)org
Subject: Re: shared memory leak in 7.0.2?
Date: 2000-08-28 15:02:02
Message-ID: 39AA7EEA.8D4E2FA7@tivoli.com (view raw or flat)
Thread:
Lists: pgsql-sql
Tom,
  Thanks for that command. I never knew that existed. The only reason I
blame postgres at this point, is that the only thing that has changed on
this machine in the past month was upgrading postgres to 7.0.2 as well
as upgrading perl.  Of the two perl is used not nearyl as much as
postgres.

  Here is the current output of that ipc command:

[root(at)kahuna pierre]# ipcs -m -a

------ Shared Memory Segments --------
key        shmid     owner     perms     bytes     nattch    status      
0x0052e2ca 0         postgres  700       144       2                     
0x0052e2c1 1         postgres  600       3769344   2                     
0x0052e2c7 2         postgres  600       66060     2                     
0x00000000 3         llee      600       46084     6         dest        
0x00000000 4         www       600       46084     11        dest        

------ Semaphore Arrays --------
key       semid     owner     perms     nsems     status      
0x0052e2ce 0         postgres  600       16        
0x0052e2cf 1         postgres  600       16        

------ Message Queues --------
key       msqid     owner     perms     used-bytes  messages    
0x00000000 0         root      700       0           0           


 If postgres were to crash for some reason. Would the shared memory be
left in never never land? If this were the case, and I'm using most if
not all of the available shared memory on startup of postgres, then this
would bring about the problems I'm seeing. Does this make sense?

 Pierre

Tom Lane wrote:
> 
> pierre(at)kahuna(dot)versions(dot)com writes:
> >   i've been running 7.0.2 for the last month or so, and I've had to
> > reboot my redhat linux box twice to clear up a shared memory leak
> > issue. Essentially with the DB running for about 2weeks with large
> > amounts of usage, eventually the Os runs out of shared memory and the
> > db crashes and fails to restart. The only way to get the db back
> > online is to reboot.
> 
> I haven't seen this reported before.  Are you sure Postgres deserves
> the blame, rather than some other package?  Postgres' use of shared
> memory is fixed for the life of a postmaster, so unless you're
> constantly restarting the postmaster I don't see how we could be leaking
> shmem.
> 
> However, rather than speculate, let's get some hard facts.  Try using
> "ipcs -m -a" to keep track of shared mem allocations, and see what usage
> is creeping up over time.
> 
>                         regards, tom lane

In response to

Responses

pgsql-sql by date

Next:From: Palle GirgensohnDate: 2000-08-28 15:56:51
Subject: pg_attribute_relid_attnam_index problem after log disk filled up
Previous:From: Tom LaneDate: 2000-08-28 14:04:00
Subject: Re: shared memory leak in 7.0.2?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group