Repository navigation
[bug]: WebUI client-side (JS) does not garbage collect memory until user refreshes the page #6677
Description
Is there an existing issue for this problem?
- I have searched the existing issues
Operating system
Linux
GPU vendor
AMD (ROCm)
GPU model
No response
GPU VRAM
No response
Version number
v4.2.6post1 + PR #6539
Browser
Firefox 128.0+linuxmint1+virginia
Python dependencies
Using Python 3.12 as per PR #6539 since Python 3.11 has been dropped from Debian Testing.
What happened
- Run InvokeAI on some server machine and make the WebUI port open to another client machine. All subsequent steps are done on the client machine, it has nothing to do with the server.
- On the client machine, open a system monitor to check your RAM. Note the starting RAM usage.
- Go to the InvokeAI Use the Unified Canvas on a large image
- Keep outpainting and doing bigger edits
- Watch your RAM go up. Wait a few minutes. Watch your RAM not go back down.
- Refresh the InvokeAI page. Watch your RAM go back down.
- Optionally, skip step 6 and watch your browser use more and more RAM until your OS starts swapping and it becomes unresponsive.
What you expected to happen
I should not have to manually refresh the page every few minutes to avoid the InvokeAI web UI hanging my computer.
How to reproduce the problem
See steps above.
Additional context
No response
Discord username
No response
Activity
psychedelicious commentedon Jul 25, 2024
Does clicking Clear Canvas History fix the issue?
infinity0 commentedon Jul 26, 2024
Clear Canvas History doesn't seem to have an immediate effect on memory usage here.
Upon further examination it appears the Web UI does occasionally garbage collect, in that my RAM usage does appear to go down from time to time. However after extended prolonged use (30-60 min, >100 1024x1024 generations) the overall usage still goes past my RAM capacity as per my original report.
infinity0 commentedon Jul 26, 2024
More specifically what I'm doing is:
Hopefully you can reproduce with these steps on Firefox ~128.
infinity0 commentedon Jul 26, 2024
The problem does not seem to exist - or exists to a much lesser degree - on Chromium 126, RAM usage is stable even after the above steps. Specifically in (2) is where Firefox RAM usage shoots up the fastest, on Chromium it hardly budges.
infinity0 commentedon Jul 26, 2024
Actually the problem does exist in Chromium, just perhaps a bit slower than Firefox. The main contributor is step (2), cycling through the images. If you cycle through the images, waiting 1-2 seconds between each arrow press, the RAM usage continues to go up, even when cycling past previously-loaded images. Clear Canvas History doesn't help, refreshing the page does help.
psychedelicious commentedon Jul 29, 2024
The high-level, declarative API used by canvas is holding references when it should be releasing them, preventing the browser from GC'ing. That API doesn't let us manage references effectively - it's too abstract.
Canvas is in the middle of a full rewrite using a lower-level, imperative API. I've put a lot of attention and care into efficiency in the rewrite and I don't see this issue there. Memory allocations are substantially reduced overall.
I don't plan on investigating this specific issue since the affected implementation is on its way out.
psychedelicious commentedon Sep 30, 2024
Invoke v5 features a full rewrite of the canvas. Please create a new GH issue if the problem still exists in the new canvas UI.