New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 593486 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 595197
issue 620852

Blocking:
issue 593485



Sign in to add a comment

Networking retains browser memory after closing tabs

Project Member Reported by ssid@chromium.org, Mar 9 2016

Issue description

Background context:go/memory-infra: memory profiling in chrome://tracing

After opening and closing tabs, memory allocated by net/ is not evicted even after 1 minute wait time after closing tabs.

The memory allocating tasks were started from:
MessagePumpLibevent 	4Mib - {this is explained by OnFileCanReadWithoutBlocking below}
net/proxy  		3.2
net/socket 		2.5
net/dns 		0.5
net/disk_cache 		0.5
net/cert 		0.3
net/spdy 		0.2
net/http 		0.2


On a different experiment the actual memory allocating files are from:
+6.3 MiB		net | cert
+2.5 MiB		net | base
+2.3 MiB		third_party | boringssl | src
+373.1 KiB		net | spdy
+360.6 KiB		net | socket


The tasks that retain memory are:
InvokeUserCallbackLater  	3.5Mib
OnIOComplete  			1.5Mib
StartInitialLoad  		1Mib
RetryOrCompleteUrlFetch  	0.5
{SocketPosix, ChannelPosix, UDPSocketPosix}::OnFileCanReadWithoutBlocking - 3.8Mib

In the traces the net/ is responsible for retaining around 10Mib of memory, out of 22 Mib memory bloat.
Trace can be found at https://drive.google.com/open?id=0B7f4beGia2iHM3l5dVlPZmtYM3M


See https://goo.gl/QNq8Mx for how the traces were taken and where the information comes from.
 

Comment 1 by ssid@chromium.org, Mar 9 2016

Cc: cbentzel@chromium.org rsleevi@chromium.org davidben@chromium.org
Adding few networking folks who can help.
There is probably plenty of room for optimizing this, but this is to be expected. We keep sockets around and other caches, independent of tab state. (The network stack is not a per-tab entity and has no idea what tabs are anyway.)

Comment 3 by ssid@chromium.org, Mar 9 2016

Labels: OS-All
Instructions for opening the trace. Use recent Chrome build. Open chrome://tracing and load the json file https://drive.google.com/open?id=0B7f4beGia2iHM3l5dVlPZmtYM3M

Click on the red dot in the first row. 
Click on "malloc" column on Browser process.
See the "Heap details" section. 
Sort with "size" column for easy reading.

Comment 4 by klo...@chromium.org, Mar 10 2016

Do we need over 10M to keep the socks around?

Can we collect data on Android to see how much are the costs there?

Comment 5 by ssid@chromium.org, Mar 10 2016

Currently it is difficult to use the tools for android, it will soon be available (crbug.com/550886). But, I am guessing it is same code path on android as well?

Comment 6 by ssid@chromium.org, Mar 15 2016

Labels: Performance-Memory

Comment 7 by ssid@chromium.org, Mar 16 2016

Blockedon: 595197
Components: Internals>Network
Status: Available (was: Untriaged)
Changing status to mute this issue from network bug triage perspective.

Comment 10 by ssid@chromium.org, Jul 14 2016

Blockedon: 620852
Project Member

Comment 11 by sheriffbot@chromium.org, Jul 17 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 12 by mef@chromium.org, Jul 18 2017

Cc: xunji...@chromium.org
Is this issue likely fixed by network stack memory work that was done?
Status: WontFix (was: Untriaged)
Let's mark this as obsolete. The data is outdated. Please let me know if you see unusual usage again. 

Sign in to add a comment