Re: PgAdmin III 1.12 crazy memory usage
От | Thom Brown |
---|---|
Тема | Re: PgAdmin III 1.12 crazy memory usage |
Дата | |
Msg-id | AANLkTi=+sYniQyXBNS=DgKX1yX2dR=sTqkRK=EUWZ4GW@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PgAdmin III 1.12 crazy memory usage (Thom Brown <thom@linux.com>) |
Список | pgadmin-support |
On 5 October 2010 11:03, Thom Brown <thom@linux.com> wrote: > On 5 October 2010 10:20, Dave Page <dpage@pgadmin.org> wrote: >> On Fri, Oct 1, 2010 at 2:32 PM, Thom Brown <thom@linux.com> wrote: >>> 2010-10-01 13:37:13 BST LOG unexpected EOF on client connection >>> 2010-10-01 13:37:12 BST LOG could not receive data from client: No >>> connection could be made because the target machine actively refused >>> it. >>> >>> This was just before I noticed the massive memory usage. I took the >>> screenshot at 13:42. >> >> I chatted with Guillaume about this, and we don't currently see how it >> could happen (clearly it did, but...). If you can figure out a way to >> reproduce, that would be a huge help. > > Okay, I've tried reproducing it by asking it to show the edit view > without restricting the number of results, but seems to be fine. But > if I open with limited to 100, then change it to "no limit", refresh > and close, the query still appears to be running on the server. It > shows "pgAdmin III - Edit Grid" as the process running the query too, > and there's still lots of I/O on the machine. I definitely don't > still have that window open. > > At this point it hasn't received any results back, so the memory usage > hasn't peaked yet. A postgres process has, however, has over 2GB of > read I/O, bearing in mind I've only used it very little today. ... > and has now reached 3GB as I'm writing this. > > I've had to kill of pgAdmin III now since it stopped responding, even > though the memory usage hadn't gone up. Postgres still appears to be > busy collecting the results. > > Tried it again, and exactly the same problem. Only happens when > initially opening the edit view with 100 rows and updating it to have > no limit, then closing it before results come back. > > And now another table which can't return results back straight away, > but would still return them after a short wait... same problem, and > pgAdmin III is bloating. It's reached 200MB and rising. Another note, pgAdmin III returns to normal memory usage once all results have been "received". But if you're selecting from a 100GB table by accident, that's not really a consolation. ;) -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
В списке pgadmin-support по дате отправления: