InvokeAI
InvokeAI copied to clipboard
invoke-ai
[bug]: WebUI client-side (JS) does not garbage collect memory until user refreshes the page
Is there an existing issue for this problem?
- [X] 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
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.
More specifically what I'm doing is:
- Generate 8 1024x1024 images (e.g. with JuggernautXL) at a time, in Unified Canvas outpaint mode, building on the previous images.
- When the generation finishes, cycle through all the images so they actually load into the browser and take up RAM.
- Accept one of the images. RAM will go down a bit, but not always all the way back down to what it was in step (1).
- Repeated steps 1-3 and watch your overall RAM usage shoot up through the roof.
- Clear Canvas History doesn't affect RAM usage directly at all. By contrast, refreshing the page does clear out your RAM.
Hopefully you can reproduce with these steps on Firefox ~128.
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.
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.
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.
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.