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@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@kahuna.versions.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
