Re: memory leak under heavy load?
От | Will Glynn |
---|---|
Тема | Re: memory leak under heavy load? |
Дата | |
Msg-id | 4390AEAC.2030906@freedomhealthcare.org обсуждение исходный текст |
Ответ на | memory leak under heavy load? (hubert depesz lubaczewski <depesz@gmail.com>) |
Ответы |
Re: memory leak under heavy load?
|
Список | pgsql-general |
> hi > i think i've encountered a bug in postgresql 8.1. > yet - i'm not reallty info submitting it to -bugs, as i have no way to > successfully redo it again. > > basically > i have server, with dual opteron, 4g of memory, 2gb of swap. > everything working under centos 4.2. > ... > what i say is that postmaster user started to "eat" memory. > it allocated *all* memory (both ram and swap), and then died. > load on the machine jumped to something around 20. I noticed a similar occurrence. We have a high-load PostgreSQL database -- not a ridiculous amount of inserts or updates, but a huge variety of diverse queries on some 200 tables. We had noticed load averages of 3-4 on our database for the past couple days. Then, this morning, Postgres got killed twice by the Linux out-of-memory process killer. (Also on a dual Opteron, 4GB of memory.) We were showing 3.5 GB of memory allocated to *something*, but stopping Postgres completely for a few seconds didn't lower the number. It wasn't taken by any process, which leads me to believe that it's a kernel bug. One reboot later, everything is rosy -- load hovers around 1.2, there's enough free memory to have a 2.5 GB buffer cache, and swap is untouched. PostgreSQL 7.4 had run on this box flawlessly for six months -- bad RAM forced us to take it down -- then again for another month until we upgraded to 8.1 last week. Like the original poster, we're set up for ~500 MB of shared memory; certainly not enough to make the kernel kill -9 postmaster. Kernel is 2.6.11-gentoo-r6, same as before the upgrade. Also, this didn't happen in our test environment, which uses a similar but x86 server. Perhaps this is AMD64 related? --Will Glynn Freedom Healthcare
В списке pgsql-general по дате отправления: