Bug 1138401

@dimstar do you think in general this issue is something that can be adressed from product side as well or only from test side?

(In reply to Oliver Kurz from comment #1)
> @dimstar do you think in general this issue is something that can be
> adressed from product side as well or only from test side?

If it's memory related, then the question would be why did the footprint increase - and possibly find a way to reduce it again. The live images run on 2GB of RAM after all

Default number of content processes in Firefox changed in version 66 from 4 to 8.

8 might be heavy for 2GB of RAM but should have changed many weeks ago already.

@dimstar ok, I suggest then that the people that are involved in submitting the changed components take a look into memory consumption. When we ask anyone from QA to do that while "Tumbleweed keeps rolling" they will be (steam-)rolled by Tumbleweed too soon ;)

(In reply to Oliver Kurz from comment #4)
> @dimstar ok, I suggest then that the people that are involved in submitting
> the changed components take a look into memory consumption. When we ask
> anyone from QA to do that while "Tumbleweed keeps rolling" they will be
> (steam-)rolled by Tumbleweed too soon ;)

which is why I filed it on boo,not poo

I do not fully understand what to do now.
Changing the default of content processes in Firefox back from 8 to 4 as a default just to pass openqa seems wrong. Changing the default back temporarily to 4 to see if it changes anything might be an option. But what if it does?

well, I doubt we have a really "openQA specific" problem. What we can do of course is change the parameters of the machine that is used for the test, e.g. give it more RAM. However I think 2GB should (still) be enough nowadays. I am not sure how that number of content processes is configured within Firefox, if this is done by upstream or in the package. However if that really makes a difference I guess setting it dynamically based on the available RAM would be nice :)

2GB for a desktop is not enough for quite some time already. Windows is even unusable with 4GB. But this just as a side note ;-)
Firefox is currently configured to 8 processes (dom.ipc.processCount) and there is no code to modify that based on number of CPUs or memory. That would be nice but is not implemented AFAICT.

// Enable multi by default.
#if !defined(MOZ_ASAN)
pref("dom.ipc.processCount", 8);
#else
pref("dom.ipc.processCount", 4);
#endif

MOZ_ASAN depends on compilation with clang which would be the default but due to SUSE's request we still build with gcc.

Anyway that being said, this can be configuration. I think we even can have an override package or something.
Like MozillaFirefox-branding-openSUSE-lowmem

But so far this discussion is based on assumptions, right? Is it possible to debug the state of such a system? Like what is using up the memory and to see if it really is memory?
Even with 8 processes after a clean startup I would not expect a massive consumption from Firefox.

The live media in openQA does not use persistence, so all changes to the filesystem are stored in RAM. This means that package installation done by openQA (there's generally no cleanup at the end) leads to ~300MiB of additional memory being used. The issues shown in the test runs don't actually appear in a 2GiB RAM VM, both firefox and oowriter work fine.

So while optimizing memory usage of firefox is a good idea in any case, this issue can likely be solved better by either not running modules which install packages in live media tests or adding a persistent overlay for all tests.

I started a test run with the former idea applied. I created a ticket for implementing the latter over a year ago: https://progress.opensuse.org/issues/34393