Thread: possible memory leak in Server Status window
Hello, all! Last Friday I've installed pgAdmin 1.12.2 (build Dec 13, 2010) into one of our clients servers (Windows server 2003 SE SP2). Postgresql 8.3.3 runs on it. As we were looking how to improve performance we were using Server Status tool (great tool, especially with recent changes - thank you for it). I have noticed that pgAdmin consumes virtual memory when the tool is running. The increment is small (~50Kb) and it happens every 6 seconds or so.. I have noticed, that even if I increase the update interval to 1minute that does not effect the MV increase - it still happens as before. Today I have opened the Server Status tool, and during an hour or so the VM size used by pgAdmin increased from 13Mb to 28Mb. I tried to reproduce the behavior on other systems but with no success yet. Could you give me a hint what I should try? -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050
Le 07/02/2011 09:31, Julius Tuskenis a écrit : > Hello, all! > > Last Friday I've installed pgAdmin 1.12.2 (build Dec 13, 2010) into one > of our clients servers (Windows server 2003 SE SP2). Postgresql 8.3.3 > runs on it. As we were looking how to improve performance we were using > Server Status tool (great tool, especially with recent changes - thank > you for it). I have noticed that pgAdmin consumes virtual memory when > the tool is running. The increment is small (~50Kb) and it happens every > 6 seconds or so.. I have noticed, that even if I increase the update > interval to 1minute that does not effect the MV increase - it still > happens as before. > Today I have opened the Server Status tool, and during an hour or so the > VM size used by pgAdmin increased from 13Mb to 28Mb. > I tried to reproduce the behavior on other systems but with no success > yet. Could you give me a hint what I should try? > Did you lower each report? because each individual report has its own timer. I have never met this kind of issue with the server status window, and noone complained yet about this. -- Guillaume http://www.postgresql.fr http://dalibo.com
2011.02.07 11:52, Guillaume Lelarge rašė: > Did you lower each report? because each individual report has its own > timer. > I'm sorry, I have only one report (Server status window). When you say "lower" do you mean "minimize" ? No, I have left it on screen. Or do you mean refresh interval? As I have single server status window, there is no window left with shorter interval. Could the answer be in Locks window? I noticed, that even when I set refresh interval to 10min, lock list is updated after the interval of approximately 1 minute. Is this expected behavior? And when having refresh interval = 10min the events of increase to VM become rare. If I hit refresh button - i can observe the increase. I still was not able to reproduce on other servers. Maybe it is related to the error we found Friday night in System log "The server was unable to allocate from the system nonpaged pool because the pool was empty." I tried to google - found an explanation that this could mean there is a memory leak in kernel or in drivers. Maybe something is wrong in system... This is the first time I encounter such a problem. -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050
2011.02.07 13:14, Julius Tuskenis rašė: > 2011.02.07 11:52, Guillaume Lelarge rašė: >> Did you lower each report? because each individual report has its own >> timer. >> > I'm sorry, I have only one report (Server status window). When you say > "lower" do you mean "minimize" ? No, I have left it on screen. Or do > you mean refresh interval? As I have single server status window, > there is no window left with shorter interval. > > Could the answer be in Locks window? I noticed, that even when I set > refresh interval to 10min, lock list is updated after the interval of > approximately 1 minute. Is this expected behavior? And when having > refresh interval = 10min the events of increase to VM become rare. If > I hit refresh button - i can observe the increase. > > I still was not able to reproduce on other servers. Maybe it is > related to the error we found Friday night in System log "The server > was unable to allocate from the system nonpaged pool because the pool > was empty." I tried to google - found an explanation that this could > mean there is a memory leak in kernel or in drivers. Maybe something > is wrong in system... This is the first time I encounter such a problem. > I'm sorry - I guess I should ask for help in pgAdmin mailing list. -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050
Le 07/02/2011 12:14, Julius Tuskenis a écrit : > 2011.02.07 11:52, Guillaume Lelarge rašė: >> Did you lower each report? because each individual report has its own >> timer. >> > I'm sorry, I have only one report (Server status window). When you say > "lower" do you mean "minimize" ? No, I have left it on screen. Or do you > mean refresh interval? As I have single server status window, there is > no window left with shorter interval. > There are a number of reports in the server status window. Each has their own refresh interval. > Could the answer be in Locks window? I noticed, that even when I set > refresh interval to 10min, lock list is updated after the interval of > approximately 1 minute. Is this expected behavior? And when having > refresh interval = 10min the events of increase to VM become rare. If I > hit refresh button - i can observe the increase. > You need to set specifically its refresh interval. But you may have found the issue. I still need to look at the code. > I still was not able to reproduce on other servers. Maybe it is related > to the error we found Friday night in System log "The server was unable > to allocate from the system nonpaged pool because the pool was empty." I > tried to google - found an explanation that this could mean there is a > memory leak in kernel or in drivers. Maybe something is wrong in > system... This is the first time I encounter such a problem. > So do I. -- Guillaume http://www.postgresql.fr http://dalibo.com