GNOME Bugzilla – Bug 727129
Multi-process model uses too much memory
Last modified: 2018-08-03 20:16:11 UTC
webkitgtk3-2.4.0-1.fc20.x86_64 epiphany-3.12.0-1.fc20.x86_64 Using the multi-process model, WebKit seems to allocate loads of memory that's probably not all dirtied, because of overcommit. After refreshing about a dozen web pages I had opened (including a few memory hungry ones) my computer cannot open new tabs (8GB of RAM, and no swap) and the behaviour is quite bad. The new opened tabs (even if the WebKit view cannot be opened) should not forget its URL. Ideally, it would use a similar model to the Raspberry Pi version of epiphany: http://www.raspberrypi.org/archives/5535 where low-memory conditions cause certain tabs to get unloaded depending on their "reloadability". So, in short, it should handle OOM conditions better and not lose opened URLs.
I'll mention the work-around, in case somebody else stumbles on the same bug: gsettings set org.gnome.Epiphany process-model shared-secondary-process
Yes, there are several things we can/should do: - Set a maximum number of web processes. This is supported by WebKit, but not exposed in our API. - Implement new process models like one web process per web site/security domain - Share always the same web process in some cases internally independently of the process model (for example about pages or even blank pages) - Of course try to handle OOM situations, but we should prevent this form happening first.
*** Bug 728352 has been marked as a duplicate of this bug. ***
We have infrastructure to suspend inactive tabs since http://trac.webkit.org/changeset/194006 I don't know how much work it is to enable it for GTK, but I see very little platform-specific code in that commit.
(In reply to Michael Catanzaro from comment #4) > We have infrastructure to suspend inactive tabs since > http://trac.webkit.org/changeset/194006 > > I don't know how much work it is to enable it for GTK, but I see very little > platform-specific code in that commit. Yes, that uses the page cache (history cache), so it is like navigating to about:blank, and then going back (but without any actual navigation, of course). We can give it a try.
(In reply to Carlos Garcia Campos from comment #5) > (In reply to Michael Catanzaro from comment #4) > > We have infrastructure to suspend inactive tabs since > > http://trac.webkit.org/changeset/194006 > > > > I don't know how much work it is to enable it for GTK, but I see very little > > platform-specific code in that commit. > > Yes, that uses the page cache (history cache), so it is like navigating to > about:blank, and then going back (but without any actual navigation, of > course). We can give it a try. I read the diff too fast. Tab suspension doesn't actually use the page cache, it only suspends the page like the page cache does, and resumes it the same way, but the page itself is not cached at all. That means that page suspension doesn't affect the memory, only performance, since a suspended tab clears all the timers, animations, rendering activities, graphics updates, etc.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/233.