Memory usage increases linearly when (un)installing modules via config import

Route building doesn't only build routes, it also triggers building at least some views caches. So a few things to look at.

Got here because I've been looking at route building as it relates to 📌 Add a cache prewarm API and use it to distribute cache rebuids after cache clears / during stampedes Needs work .

A possible thread to pull on: I was busting a 650M limit when syncing config and uninstalling 9 modules. By adding the following it can now run with a limit of only 350M:

function MYMODULE_modules_uninstalled($modules, $is_syncing) {
  if ($is_syncing) {
    \Drupal\Component\FileCache\FileCache::reset();
  }
}

We are experiencing the same problem where enabling modules consumes all of our memory.

Re #6 Looking more closely I think that's at least partly due to the site using the contrib Plugin → module which has a plugin cache with a collection name that includes the hash of all enabled modules, meaning that as modules are (un)installed the cache keeps growing IIUC. I'm not sure how much memory that was actually taking up for us, but it could be part/all of the problem for some folk.

@yovince do you use the plugin module by any chance? If so you might see some savings by adding this to a custom module:

function MYMODULE_modules_installed($modules, $is_syncing) {
  if ($is_syncing) {
    \Drupal\Component\FileCache\FileCache::reset();
  }
}

We don't use the plugin module, I'll test adding the file cache reset anyway and see if it helps.

I just encountered the same issue and tried to debug it using memprof, but couldn't really figure out the root cause. If anyone else wants to have a go, I attached the profile. Had to add the .txt extension to be able to upload it.

Tried adding the file cache reset, but that doesn't help in my case. I dove a bit more in the profile, but I can't figure it out. Rebuilding the router triggers a lot of code, including route subscribers that indirectly load a bunch of config and build plugin definitions, so it's kinda hard to pinpoint where exactly memory is leaking.

📌 Memory leak in DrupalKernel when installing modules Active may possibly have helped here.

📌 Experiment with removing the static cache from filecache Active would do the same as the FileCache::reset() (but also never use that memory in the first place).

Also 🌱 Reduce memory/cpu/io cost of attribute discovery Active .

Also 📌 Review Route rebuild in ModuleInstaller Active .