Is this a web console memory leak in IE7 and IE8 on Windows?

Hi Victor,

Do you mean the membase process itself or the browser footprint?

For the membase process, you should expect to see on average around a 150mb footprint and zero cpu for a idle instance of membase without data.

-Alex.

Hi Alex,

It's the browser footprint.

And here are some more findings:

• After the browser footprint grew, by refreshing the page in the browser I can release about 10-30MB memory but it never goes back to the level when the page first time loaded.
• Logout seems doesn't help although I thought that releasing the page should cause the browser to release all stuff associated with that page.
• I can observe the same issue in Chrome (v14.0.835.163 ) and FireFox (v4.x) (both are Windows version). I'll try out the FireFox 6.0 later.

Best regards,
Victor

An update:

Browser memory footprint growing in FireFox 6.0.2 for Windows observed with Web Console page loaded. Started with 96MB and after about half an hour it's around 180MB.

Just to confirm again, it is your FireFox or IE process whose memory is growing constantly, not the Membase process(es) right?

Yes you are correct. The memory footprint of Membase processes (erl.exe and erlsrv.exe if I understand correctly) is stable even after a stress test we just done, while after that stress test the browser process grew to 400MB.

victor, do you see this behavior on other html5/flex heavy web sites with your browser? How much memory is generally on the machines you access membase from?

Hi Alex and Perry,

I am looking at this issue because I think that when we deploy Membase to production the operation team shall open the Web Console monitoring page in browser on 24x7 basis. So if the browser memory footprint will grow continously then they need to close and reopen the page in browser periodically, which could be annoying.

And for Alex's two questions:

1. Yes I "did" see this behavior before.

One of our web sites ever hit this problem in Windows based web browser during development phase, and I think that both web sites (ours and the Web Console) shares the same characteristic (which is also the root cause of the leaking in our web site): The web page uses AJAX calls to continously pull data from server and update the page content without refreshing or reloading the page. So any dynamically created HTML DOM or JavaScript object that not properly disposed will remain in memory and pile up as time goes by.

We finally stopped most of the leaking in Windows based web browsers (we don't target non-Windows wbe browser) after a long memory leaking hunting run. Some of the leaking cases are bugs in specific browser and our workaround is to do a full page reload in next auto-update action after a designated timespan has elasped.

2. Currently I installed Membase server in two machines and browse the Web Console page locally (i.e., from http://localhost:8091). So the machine is both the hosting box of Membase server and the web browser that visits Web Console page.

One machine is my development machine with Windows XP 32bit 4GB RAM (so yes only 3.5GB usable). The other is a demo machine with Windows Server 2008 64bit 16GB RAM.

Today I open the monitoring page http://localhost:8091/index.html#sec=analytics&statsBucket=/pools/defaul... and it looks that browser process' memory grows faster because there are lots stuff to update. Both machine's browser process grows to about 900MB after 8 hours.

I also tried to boot 3 web servers in the Windows XP machine so that the memory pressure is high (one web site starts to log "out of memory" exception), and the browser process still holds the memory. So it should be less likely caused by browser's garbarge collection strategy.

Hope that the above info helps :)

Best regards,
Victor

Victor - don't have a immediate fix for you but we did create a bug for this and its being tracked for 2.0 against IE 8, FF 4+, chrome and safari.