Re: shared memory leak in 7.0.2?
От | Pierre Padovani |
---|---|
Тема | Re: shared memory leak in 7.0.2? |
Дата | |
Msg-id | 39AA7EEA.8D4E2FA7@tivoli.com обсуждение исходный текст |
Ответ на | shared memory leak in 7.0.2? (pierre@kahuna.versions.com) |
Список | 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@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
В списке pgsql-sql по дате отправления: