Repository navigation
Memory hog: Update checks never release memory to the system - #2438
lewisgoddard wants to merge 3 commits into
Conversation
…ates Each change to a flatpak installation fires many FileMonitor events, and every event queued a full reload of both AppStream pools. With no debounce and no re-entrancy guard, routine flatpak activity stacked reloads whose large transient allocations ratcheted RSS to a multi-hundred-MB high-water that glibc never returned, so an idle --silent daemon sat near a gigabyte. Coalesce the monitor events into a single refresh once activity settles, guard trigger_update_check so refreshes cannot stack, and malloc_trim() after each update check to hand the freed transients back to the OS.
|
|
||
| reload_installed_packages (); | ||
| yield get_updates (null); | ||
| } while (update_check_pending); |
There was a problem hiding this comment.
If I understand this correctly, this allows an update check to be queued up during an already running update check? Do we have a situation where we want the second check to happen at all? You can't run a flatpak update command while some kind of operation is happening via AppCenter, right?
There was a problem hiding this comment.
It was getting triggered by the file monitoring of other states, like installs and uninstalls, plus external tools can make changes to things like sources to trigger an update. I've changed this around to trigger refreshes less often and not queue additional updates.
The only catch is now making a change to sources and running a refresh will get a stale result if it happens while a refresh is already running.
There was a problem hiding this comment.
Maybe @danirabbit has some opinion here but I feel like only enthusiasts will really run into a situation like that, so I personally am not too worried about it.
AppCenter's own install, update and remove jobs were triggering refresh
malloc_trim()after each update check to hand the free'd memory back to the OS.Free's ~500MiB outside of update checks.