Workaround for high `tutor dev` memory usage in Palm and Nightly

The good news: Tutor has been keeping up with improvements to Open edX frontends. Since Palm, Tutor now runs nine different micro-frontend apps by default!

The bad news: In development mode (tutor dev), this results in very high resource consumption, since each micro-frontend uses its own Docker container. Depending on how much memory you have, running tutor dev start in Palm or Nightly might freeze your machine.

The workaround: You can lower tutor-dev’s resource consumption by creating a simple plugin that disables the MFEs that you don’t strictly need. Create a file at "$(tutor plugins printroot)/":

from tutormfe.hooks import MFE_APPS

MFES_TO_KEEP = ["learning", "gradebook", "course-authoring"]

def _remove_extra_mfes(apps: dict) -> dict:
    return {
        app_name: app
        for app_name, app in apps.items()
        if app_name in MFES_TO_KEEP

Then, enable it, and re-initialize the MFE plugin:

tutor plugins enable fewermfes
tutor config save
tutor dev do init --limit=mfe
tutor dev reboot

You can modify MFES_TO_KEEP to suit your needs. Remember to disable this plugin before using production mode (tutor local), unless you want to run the deprecated frontends!

Longer term: We are working on improvements to tutor-mfe so that tutor-dev will only use a single Docker container, regardless of how many micro-frontends are installed: Support `npm start` on host for MFE development · Issue #123 · openedx/wg-developer-experience · GitHub


Is the fact itself there are many node containers affects so much? Or maybe the fact we have 9 webpack devservers running? What is the expected effect if we put all those devservers in a single “jar”? Will it resolve the situation? Possibly, putting only a configurable subset of MFEs into a dev mode could help… Just a thoughts: what is resources diff MFE with devserver vs built-n-served? :thinking:

1 Like

Great question @bergman . I imagine that having a single devserver instead of 9 would make a big difference. I don’t know how hard that would be to implement.

Yes, if I understand you correctly, that is what @brian.smith is working on now. The resource difference is very significant!

1 Like

I have a candidate solution to the high memory/cpu issue: fix: high memory/cpu usage in dev by regisb · Pull Request #137 · overhangio/tutor-mfe · GitHub

Let me know what you think by adding your comments to the PR. I’m particularly interested to learn if it works for you! (it works for me)

1 Like