about:performance can provide the tab/pid mapping, with some performance indexes. This might help solve your issue listed in the side note.
Best Regards, Shih-Chiang Chien Mozilla Taiwan On Thu, Nov 2, 2017 at 3:34 PM, Randell Jesup <rjesup.n...@jesup.org> wrote: > [Note: I'm a tab-hoarder - but that doesn't really cause this problem] > > tl;dr: we should look at something (roughly) like the existing "page is > making your browser slow" dialog for website leaks. > > > Over the last several months (and maybe the last year), I've noticed an > increasing problem in websites: runaway leaks, leading to > a poorly-performing browser or OOM crashes. Yes, these have *always* > occurred (people write bad code, shock!), but the incidence seems to > have gotten much worse 'recently' (anecdotally). > > This may be the result of ads/ad networks (in some cases it provably > is), in other cases it's the sites themselves (like the 4M copies of > ":DIV" that facebook was creating over a day if you left a message > visible, plus GB of related leaks (80K copies of many strings/objects). > Many of the pages causing these leaks are major sites, like nytimes.com, > washington post, cnn, arstechnica, Atlantic, New Yorker, etc. > > However, regardless of who's making the error or the details, I've been > noticing that I'm having to "hunt for the bad tab" more and more > frequently (usually via about:memory, which users wouldn't > do/understand). Multi-e10s helps a bit and some tabs won't degrade, but > also enables my system to get into phyical-memory-pressure faster. (The > machine I notice this on is Win10, 12GB ram, quad-core AMD 8xxx (older, > but 3.5GHz). I'm running Nightly (32-bit) with one profile (for > facebook), and beta (64bit) with another profile). > > While physical-memory pressure causes problems (including for the system > as a whole), the leaking can make Content processes unresponsive, to the > point where about:memory doesn't get data for them (or it's incomplete). > This makes it hard-to-impossible to fix the problem; I kill Content > processes by hand in that case - regular users would just force-close the > browser (and perhaps start Chrome instead of restarting.....) We see an > insanely high number of OOMs in the field; likely this is a major > contributing factor. Chrome will *tend* to have less tabs impacted by > one leaking, though the leaking tab will still be ugly. > > Sometimes the leak manifests simply as a leak (like the washington post > tab I just killed and got 3.5 of the 5GB in use by a content process > back). Others (depending I assume on what is leaked and how it's kept > alive) cause a core (each) to be chewed doing continual GC/CC (or > processing events in app JS touching some insanely-long internal > structure), slowing the process (and system) to a crawl. > > > *Generally* these are caused by leaving a page up for a while - navigate > and leave, and you never notice it (part of why website developers don't > fix these, or perhaps don't care (much)). But even walking away from a > machine with one or a couple of tabs, and coming back the next day can > present you with an unusable tab/browser, or a "this tab has crashed" > screen. > > > Hoping site owners (or worse, ad producers) will fix their leaks is a > losing game, though we should encourage it and offer tools where > possible. However, we need a broader solution (or at least tools) for > dealing with this for users. > > > I don't have a magic-bullet solution, and I'm sure there isn't one given > JS and GC as a core of browsers. I do think we need to talk about it > (and perhaps not just Mozilla), and find some way to help users here. > > > One half-baked idea is to provide a UI intervention similar to what we > do on JS that runs too-long, and ask the user if they want to freeze the > tab (or better yet in this case, reload it). If we trigger before the > side-effects get out of hand, freezing may be ok. We should also > identify the tab (in the message/popup, and visually in the tab bar - we > don't do either today). This solution has issues (though freezing tabs > now that "slow down your browser" does too, but it's still useful > overall). > > We can also look at tools to characterize site leaks or identify > patterns that point to a leak before it gets out of hand. Also tools > that help website builders identify if their pages are leaking in the > field (memory-use triggers? within-tab about:memory dumps available to > the page?) > > Perhaps we can also push to limit memory use (CPU use??) in embedded > ads/restricted-iframes/etc, so sites can stop ads from destroying the > website performance for users over time. I've often seen ads taking > 300MB-2GB. > > I'm sure there are better/more ideas - suggestions? What thought has > gone on in the past? (this *can't* be a new observation or idea) > > > > Also, I suspect that website behaviors/leaks like this are part of why > many users have developed a habit of browsing and closing, opening few > tabs at any point in a session (since leaving them open *sometimes* > hurts you a lot). > > Part of why I care about this is that I'm looking at how far we can go > with multiple content processes, site isolation, and moving (more) > security-sensitive and/or crashy services into separate processes -- all > of which come into play here. > > Side-note: removing the process-id from tabs in mult-e10s has made it > harder for me to hunt down offending tabs, since I track down runaway > memory/CPU in things like Process Explorer. (Usually after I notice > that the browser has gotten slow/non-responsive) Totally reasonable, > though I'd like to see the ID back on Nightly at least - makes starting > GDB against the right content process *much* easier, and I don't have to > limit the browser to 1 to avoid the problem. > > -- > Randell Jesup, Mozilla Corp > remove "news" for personal email > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
