Tabs are discarded when there is plenty of free memory |
||||||||
Issue descriptionChrome Version: 69.0.3463.0 (Official Build) canary (64-bit) (cohort: Clang-64) OS: Windows 10 What steps will reproduce the problem? (1) Just use browser as normal (2) walk away for a bit, maybe leave it for a few hours or overnight. (3) What is the expected result? Tabs don't get discarded What happens instead? ALL my tabs except the one in focus get discarded, when switching to them, they reload, slowing me down. This is on my personal computer, a system with total of 32Gb of ram. There is currently 16Gb of memory free and unused, there is no reason that tabs should be being discarded when I have 16Gb of memory free. I wish for my memory to be used, not for the tabs to take a long time to load when I switch to them. Please use labels and text to provide additional information. If this is a regression (i.e., worked before), please consider using the bisect tool (https://www.chromium.org/developers/bisect-builds-py) to help us identify the root cause and more rapidly triage the issue. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Jun 21 2018
hello, I wonder if there was any comment on this bug? In particular, are we measuring how often users now have to wait for their tab to reload when switching to it, rather than it just being there for them? I think if a user is under no memory pressure then unloading a tab and forcing it to reload is a strict regression in behavior.
,
Jun 21 2018
There was a bug https://crbug.com/854272 prior to Chrome 69.0.3466.0 that caused tabs to be frozen/discarded more than intended. Feedback for earlier versions of Chrome is therefore not actionable. We do want to discard tabs when we predict that they won't be reused, even when there is no memory pressure, because we know that letting a user hit memory pressure is a bad experience. We need to act before that. That being said, the number of tabs that can be open before we start discarding will be proportional to the amount of physical memory (users with more memory can have more tabs before we start discarding). More details about how we will evaluate the success of this experiment will be available in an upcoming doc. You are right that time spent waiting for discarded tabs to reload should be taken into account.
,
Jun 21 2018
okay thanks, I don't think issue 854272 would be affecting me since these are not loaded in the background, they are just idling after I switch to another tab. I will try restarting to get beyond 3466 though! Currently I have a ton of these tabs unloaded - http://shortn/_5ck4wNyVD4 - but I am nowhere near hitting memory exhaustion; Windows is showing 22Gb in use, but 34Gb available, lots of memory to hold tabs, but switching to any of these discarded tabs can take several seconds to load.
,
Jun 22 2018
I wonder if PageLoad.Experimental.PaintTiming.ForegroundToFirstMeaningfulPaint would be a good metric here? This is described as "Measures the time from a background tab being switched to the foreground to the time the first meaningful paint is performed, for main frame documents." If so, I see regressions for the freezeanddiscard group that I believe I am in https://uma.googleplex.com/p/chrome/variations?sid=12d0641bf63d0bb0dfab79aff0db5152
,
Jun 25 2018
A pinned tab of mine just got discarded! Should I raise a new bug about this?
,
Jun 27 2018
,
Jul 24
Pinned tabs: There is no special protection for these tabs. We found that pinning is not a good predictor of whether the tab will be reused. Metrics: In the latest version of our experiment, we see no effect [1] or improvements for most heartbeat metrics and for PageLoad.Experimental.PaintTiming.ForegroundToFirstMeaningfulPaint. More detailed analysis will be available in the PRD. The discarding and freezing logic is much more conservative in Chrome 69.0.3497.4+. Please let us know if you are unhappy with the new behavior. [1] Event.Latency.ScrollBegin.Touch.TimeToScrollUpdateSwapBegin4 is moving in the wrong direction... this should be investigated.
,
Jul 25
I have not noticed over-discarding for a while now, so I think whatever changes to the algorithm were made are great. But then, I'm speaking from a machine with 64Gb of memory so I assume the algorithm would never discard tabs (maybe this is distorted view!) nevertheless, since this bug does not affect me any more, I'll close it off. Thanks for listening!
,
Jul 31
This started happening again for me this week. Chrome Version: 70.0.3507.0 (Official Build) canary (64-bit) (cohort: Clang-64) On my machine, I see 16 tabs discarded (loading state is "unloaded"). Total of around 40 tabs. Some of the discarded ones are high site engagement, so sounds like a bug? When I switched to them, I had to wait for them to reload, which was quite slow. I have 38Gb of memory free. Here is a list of the tabs from chrome://discards - http://shortn/_1mR9SnFi5C (Google Only). My variations: c134752e-70ea8f25 2c707b42-1b19e7d4 411b6d4e-f23d1dea fe69e053-83ce3e87 d01ab0d3-ca7d8d80 265533-3d47f4f4 1a0d11d4-3f4a17df 16e0dd70-3f4a17df ebeb14fc-3f4a17df b7e2524c-3f4a17df 3cd9377c-ca7d8d80 da89714-4ad60575 64da5c1e-7bc2af31 fb88346a-9f192e4b 8982496f-ca7d8d80 b1681d28-803f8fc4 61832c80-f23d1dea cc20827f-ca7d8d80 9041608a-3f4a17df 8502ae4f-f23d1dea 6025934e-3f4a17df c27fec31-c982d8da 7c1bc906-b5809d46 47e5d3db-3d47f4f4 125b7f68-65bced95 d442dfb7-eeca42f7 9ca1387e-f23d1dea 41e765a5-f23d1dea 1149accc-65bced95 a582a1b8-ad75ce17 495970ba-ca7d8d80 3042ad4b-ca54bb47 ebbb4e0a-ca7d8d80 591576c8-ca7d8d80 e56c5101-803f8fc4 267255c3-f4950e99 e463c247-6ab49ebf 44827ee5-43146c13 27cd6737-3f4a17df 826d9edf-f23d1dea edbcf7c5-adf3d98f 5485fc4d-3d47f4f4 de47491b-f23d1dea 9773d3bd-ca7d8d80 93731dca-e89d496c 41f007f9-41f007f9 9b4c4257-592e7888 8fa604e0-1a6e73b1 43f62d3b-4e24087b c992f345-4ad60575 165e16d1-3f4a17df 9e5c75f1-e406a769 350fabdd-34b13816 da92f51d-3d47f4f4 6fa07eb4-ca7d8d80 f2fd8aaf-e71b878b f79cb77b-3f4a17df 5c40534c-ca7d8d80 2ca9c26b-3d47f4f4 7a5ba892-f23d1dea d1cd70a5-1500dc1d 4ea303a6-390a4c82 514f6bcf-ca7d8d80 3d7e3f6a-2eb01455 6e6e0c7e-bfd1fe3 95876445-ca7d8d80 d92562a9-65bced95 7aa46da5-c946b150 74c3667-6ab49ebf dc5b1f29-dc5b1f29 2c1d398c-3f4a17df de52c077-65bced95 6973a1cf-3f4a17df cc54eb06-3f4a17df cac0a91c-77662737 58a025e3-36e97b2c ad6d27cc-7075cd8 2a32876a-70ea8f25 f3ea30a0-84708353 23496387-232b3cab 5a42b5d9-3f4a17df 344833e9-473e8c2e 3f273a97-25a103a9 4bc337ce-4077d4f3 caaf551e-f23d1dea 9a2f4e5b-3fe9c4dc 494d8760-52325d43 3ac60855-3ec2a267 f296190c-9ce370dd 4442aae2-6e597ede ed1d377-e1cc0f14 12e17bc5-e1cc0f14 75f0f0a0-d7f6b13c e2b18481-6e597ede e7e71889-4ad60575 f9e5da91-f23d1dea bcf40d1d-ca7d8d80 6a51bb09-f23d1dea 308674c4-ca7d8d80 cc73f8a1-a2d707c6 10a311eb-f23d1dea 8834fcca-cf4f6ead ea0f933d-6ab49ebf
,
Aug 3
,
Aug 3
Thanks for the info and for the debugging data, I'll look into this.
,
Aug 3
FYI Proactive Tab Discarding shouldn't happen unless you have > 100 tabs open on a machine like yours (we allow 3 tabs per GB of RAM, capped at 100). We'll still freeze the tabs that shouldn't suffer from this (e.g. tabs with static content). I'm suspecting that this issue is similar to 869414, you probably did something that cause the memory usage to spike (temporarily) and this triggered the reactive tab discarding (this is still a bad experience that needs to be fixed). I think that it'd be worthwhile augmenting the chrome://discards UI to indicate why a tab has been discarded (and we should also show the Discarded state in the Lifecycle state column). I'll look into this.
,
Aug 3
Thanks for your feedback. Yes, discarding tabs is a really poor user experience, they reload, and you lose state (e.g. if a page has refreshed since the discard, you lose what it was before the refresh). Also, there's just the time you have to wait for the tab to reload, which is a pain. I think we need to be more conservative here. I think discarding only when the system starts swapping would be the most conservative way here.
,
Aug 3
When I say "Proactive Tab Discarding shouldn't happen unless you have > 100 tabs" I mean that this is the current expected behavior (see https://cs.chromium.org/chromium/src/chrome/browser/resource_coordinator/tab_manager_features.cc?l=163). Note that the timeouts value listed here are based on an usage clock that only advances when Chrome is in use. So I guess that your system entered a high memory pressure state and this triggered urgent tab discarding. I'll run some experiments on my machine to try to confirm this. I'll also look at fixing the chrome://discards UI, the "Lifecycle State" column currently doesn't display the status of an unloaded tab (unloaded can mean that it hasn't been loaded yet or that it has been discarded).
,
Aug 3
okay now pretty much all my code review tabs are discarding when I flip away from them. This is making it impossible to use Chrome, so I will be disabling the experiment on my machine. --disable-features=ProactiveTabFreezeAndDiscard,PageLifecycle,SiteCharacteristicsDatabase,ThrottleAndFreezeTaskTypes Please let me know when the logic is changed, so I can opt back into the experiment. I do not think this feature is ready to ship.
,
Aug 4
Thanks for the info, this is really not the expected behavior. I'll raise this issue to the chrome-catan@ team and we'll discuss what to do about this. This sounds similar to issue 870794, it looks like you had ~200 tabs open when reporting #16? Do you remember if a lot of them had an 'X' in the 'Can Freeze'/'Can Discard' columns? (my current hypothesis is that the last used tabs get discarded because this is the only eligible ones). You might want to keep the 'SiteCharacteristicsDatabase' feature enabled as this doesn't cause any discarding and this will improve future freezing/discarding intervention.
,
Aug 6
Thanks, I think something that did not discard a tab that had recently been restored, would have solved this issue. In this pathological case, I was flipping between two tabs and each time I flipped away, one would get discarded, then the other. I think I did have a lot of tabs at the time, but I was not reaching anywhere near memory usage that would have triggered swapping.
,
Aug 31
There is now no experiment group where a tab can be discarded less than 10 minutes after being hidden. Therefore, the issue where tabs are discarded when you switch quickly between 2 tabs should no longer exist. In most experiment groups, no discard is possible for less than 1-day old tabs if you have less than 4 tabs/GB of RAM. There is a group which we don't plan to ship to stable in which discard can happen after 1 hour even if you have less than 4 tabs per GB. If you're not satisfied with your current tab discarding experience, please provide your variation hashes from chrome://version. Thanks!
,
Oct 8
This is back, as of today! Verison is: 71.0.3573.0 (Official Build) canary (64-bit) (cohort: Clang-64) Variations: c134752e-70ea8f25 2c707b42-ca7d8d80 411b6d4e-3f4a17df b7d3b6c2-3f4a17df fe69e053-83ce3e87 d01ab0d3-614f7c0c b0271b40-a3bfba63 f993cd1-3d47f4f4 16e0dd70-3f4a17df 66df3e9d-acb92ace 2b6b7805-f23d1dea ebeb14fc-3f4a17df b7e2524c-502eac8f da89714-4ad60575 6c18ba9d-f23d1dea 64da5c1e-5e8c63f 8982496f-f23d1dea 61832c80-f23d1dea cc20827f-6463c988 1d411afe-799a7f5e 9041608a-3f4a17df 5852bcb0-a75ab0e 241fff6c-f23d1dea c6c1fc26-3d47f4f4 6025934e-3f4a17df c27fec31-cf4f6ead 7c1bc906-86bf56d9 9def365c-f23d1dea 125b7f68-65bced95 d442dfb7-ca7d8d80 9ca1387e-f23d1dea 41e765a5-f23d1dea 6557d030-6557d030 ab3d6cfd-3f4a17df 34d450b1-1e3c02a2 f75ce29e-f23d1dea a582a1b8-ad75ce17 8f4db35c-3f4a17df 495970ba-ca7d8d80 31e1328a-ca7d8d80 e56c5101-ad2fa222 e463c247-c40fe774 764fc084-3f4a17df aa011017-a2d707c6 334aa58d-f23d1dea d998b63-c01d2e63 f719c9bd-8badbd24 edbcf7c5-adf3d98f 5485fc4d-3d47f4f4 93731dca-e89d496c e111fcd-3f4a17df 41f007f9-41f007f9 9b4c4257-592e7888 1b558915-3f4a17df 9874ae0-3f4a17df 43f62d3b-cf4f6ead 4ae380f4-3f4a17df c992f345-ca7d8d80 165e16d1-3f4a17df 9e5c75f1-e406a769 67fc9f6f-65bced95 6872f671-991e1e1 2594bdf4-3e4b89c4 350fabdd-34b13816 6fa07eb4-ca7d8d80 4934552d-f23d1dea 2ca9c26b-3f4a17df 2fccc5d5-855be3dd 2b08b14-f23d1dea 7a5ba892-3f4a17df d1cd70a5-70ea8f25 4ea303a6-3d47f4f4 95876445-ca7d8d80 d92562a9-65bced95 fc369826-3f4a17df 7aa46da5-c946b150 67246da1-f23d1dea de52c077-65bced95 58a025e3-36e97b2c ad6d27cc-7075cd8 2a32876a-70ea8f25 8576baf1-3f4a17df f3ea30a0-3f4a17df 23496387-4ea78229 2e7f6029-c5dfd7a3 51af0496-8fbdaf71 1fcbb124-9aaad08b 344833e9-473e8c2e 3f273a97-25a103a9 4bc337ce-87ea0e5e 494d8760-52325d43 3ac60855-3ec2a267 f296190c-9ce370dd 4442aae2-6e597ede ed1d377-e1cc0f14 75f0f0a0-d7f6b13c e2b18481-6e597ede e7e71889-4ad60575 5e60f31d-803f8fc4 6a51bb09-ca7d8d80 b0ea13bc-3f4a17df 94e68624-3f4a17df cc73f8a1-ca02b375 10a311eb-f23d1dea 6204e469-3f4a17df 3f33c9bd-332ab290 81c6897f-741d8d64 3a17127a-65bced95 This is happening on many tabs, and I am nowhere near running out of memory. Have the experiment parameters been changed again?
,
Oct 8
my hangouts chat tabs are being 'frozen' proactively now, which means I no longer get notifications when someone @ me or types in a conversation I started. See chat_discard for the tab frozen. See it_is_blue.png for the tab icon as I see it when I have not switched to the tab in a while because it's been frozen. Immediately I switch to it, however, I get it_had_a_notification.png which is the notification coming through late, as the chat was paused and unable to detect a chat had been waiting for me and update the icon color to red. This seems like a serious regression, can the change that caused the extra-super-proactive discarding and freezing be reverted while this is resolved?
,
Oct 9
Thanks for all the data. The problem is that the ProactiveTabFreezeAndDiscard feature is enabled in your chrome://flags but the SiteCharacteristicsDatabase isn't. The database was previously enabled for all Googlers but the feature has recently expired, without it you're missing a lot of important heuristics that help decide if a tab can be frozen/discarded (the main goal of the DB is to ensure that we don't discard/freeze a tab that might try to communicate with the user while in background). I just got approval to ship the DB at 100% on stable, I'll turn it on by default on trunk and I'll go update our experiments. FYI we don't have any clear plan on when we'll enable tab discarding, we decided to focus on tab freezing (which is usually harmless when the database feature is enabled).
,
Oct 9
Thanks for the update. I didn't see the other discarding option in chrome://flags! Given the impact (of even freezing) on my workflow I've just disabled the feature entirely for the time being, but please let me know if you are needing more people to test as you get closer to launch and I can flip them both back to Default. For hangouts chat, is there an API where they can prevent freezing/discarding entirely?
,
Oct 9
Hangout/Chat should be protected by the Intervention Policy Database, could you check in chrome://components which version of the "Intervention Policy Database" you have?
,
Oct 9
Version 2018.9.6.0 - but you said in #25 that SiteCharacteristicsDatabase was disabled, so I shall wait for that to be re-enabled and try again?
,
Oct 9
These are 2 different features (sorry for all the confusion here!): - Site Characteristics Database: This is a local DB, it uses local observations to determine if a given Origin might try to communicate with the user while being loaded in background. See https://docs.google.com/document/d/1MgyIJ096pQChpbqQIqXHTZ0NYRXAOxcBtAq2lJplOpE/edit#heading=h.5ugemo7p04z9 for more details. - The Intervention Policy Database: This is a global DB that we ship as a Chrome Component, it allows enabling/disabling some interventions for some specific Origins. See https://docs.google.com/document/d/1KzsBLIKx3Xg0NUqny0lBxbI5POZu0q_8TkzerWx5CBU/edit?usp=sharing for some design details. The version you have is the right one so in theory you shouldn't see any discarding/freezing for Chat/Hangout, I'll look at this.
,
Oct 10
thanks. I can re-enable the features and report whether chat is still frozen, if that would help.
,
Oct 10
Thanks, I've updated our Finch config and your issues should have been addressed (there's still an issue with the Global DB but it's not a big deal in your case I think). You can just switch your flags to the Default value and let us know if you have any issue. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by wfh@chromium.org
, Jun 18 2018