GNOME Bugzilla – Bug 728352
Epiphany (and WebKitGtk+) uses too many resources when in "one-secondary-process-per-web-view" mode
Last modified: 2015-12-16 13:28:39 UTC
Ephy 3.12.0 and WKGtk 2.4.1 compiled with JHBuild I'm a heavy Ephy user (as its stability is great nowadays) and have plenty of windows (12) and tabs (let's say ~10 per window?) Now, with the "one-secondary-process-per-web-view" mode, I have a lot of processes running and opened file descriptors. I have bumped into the problem that I need to use a chroot for my development and I'm getting this messages when trying to use it when Ephy is running: bash: Resource temporarily unavailable It seems I'm hitting some kind of limit in my GNU/Linux box (Ubuntu 13.10), although I have not been able to figure exactly which. I've raised the limit of open file descriptors but it has not helped. With Ephy in "one-secondary-process-per-web-view" I have ~18000 file descriptors opened out of ~28000. I've changed to "shared-secondary-process" and my problems have disappeared. With this, I have ~200 file descriptors opened out of ~8000. I'm unsure this is an actual bug in Ephy or WKGtk but I think we should address this as a potential problem for our users in GNOME.
Created attachment 274470 [details] List of open file descriptors by a single WebKitWebProcess in Ephy
Created attachment 274471 [details] List of open file descriptors by a single process in chromium
Added two list of process launched by Ephy and Chromium in similar "1 process per tab" mode. Noticeable, Chromium even gets more file descriptors. I wonder how they are facing this problem. I also wonder if their sandboxing mechanism may help them here somehow.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 727129 ***
(In reply to comment #4) > Thanks for the bug report. This particular bug has already been reported into > our bug tracking system, but please feel free to report any further bugs you > find. > > *** This bug has been marked as a duplicate of bug 727129 *** I'm not sure we are talking about the same bug here. I mean, we can transform bug 727129 in a more generic one but what it was reported here was that the "one-secondary-process-per-web-view" mode is problematic because it is creating too many file descriptors. That problem is different than just using too much memory. FWIW, my problem when reporting this bug was not that too much memory was used but that because these many file descriptors I was hitting a limit set by the kernel. What do you think, should I reopen or leave as it is?
Reopening since I honestly believe we are talking about different things than bug 727129. --- I'm using WebKitGtk+ with my own JHBuild setting: https://github.com/tanty/jhbuild-epiphany/tree/master Epiphany 3.18.0 and WebKit 2.10.4 I'm running Epiphany with the dconf key: "process-model" = "shared-secondary-process" The compilation was done with CMake args: '-DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DDEVELOPER_MODE=ON -DCMAKE_C_FLAGS_DEBUG="-O0 -g1" -DCMAKE_CXX_FLAGS_DEBUG="-O0 -g1"' --- Today, one of the tabs failed to load. No SIGSEVs nor any kind of crashes. This is what I see in the error output: ... Failed to create shared memory file /WK2SharedMemory.2347425006: Too many open files Failed to create shared memory file /WK2SharedMemory.2078275081: Too many open files Failed to create shared memory file /WK2SharedMemory.2879760070: Too many open files Failed to create shared memory file /WK2SharedMemory.3712558436: Too many open files Failed to create shared memory file /WK2SharedMemory.3835635806: Too many open files Failed to create shared memory file /WK2SharedMemory.4122325227: Too many open files Failed to create shared memory file /WK2SharedMemory.1002315265: Too many open files ... This continues for a long, long output. --- Finally, the WebProcess SIGSEVed with the following bug: https://bugs.webkit.org/show_bug.cgi?id=150899
Just filed the following bug: https://bugs.webkit.org/show_bug.cgi?id=152316 Probably, this could be closed and just point to that WK bug.