Hey want to see if there is any follow-up on this.

Just looking for a way to disable a couple of flags per the whole machine instead of per user. Found they are taking up large amounts of CPU/Memory and I really don't need the flag running.

-offline-auto-reload

I doubt that enable-offline-auto-reload is the issue here but perhaps because it is failing to load a page because of network access and then offline-auto-reload is successful once the network is available?

Do you know what types of processes the chrome processes are? Grab a snapshot from the Chrome Task Manager (from Hamburger Menu, More Tools > Task Manager) inside Chrome.

I don't think we have a network issue, the environment we are in is a hosted environment with a few safeguards to protect from total network outage. While reviewing there was no noted issues with connection to any sites, really the only page open was the new tab page. 

Please see screenshot for the Chrome Task Manager. 

Deleted: Chrome_Tasks.JPG 26.9 KB

	Chrome_Tasks.JPG 26.9 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Right so you are seeing the browser process, a single render process and a GPU process. That is the typical number of chrome processes.

Does this really change if you use the -offline-auto-reload?

In the Google Chrome task manager no, but in Windows Task manager is where I am seeing the additional 4-5 processes running for -offline-auto-reload. 

Thank you for providing more feedback. Adding the requester to the cc list.

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

Any response on this

A Gentle ping...

@ dtapuska@chromium.org: Requesting you to please respond to comment#7. Adding Needs-Feedback label to it.

Thanks..!

Sorry I don't know. This is out of my scope.

Bruce might be helpful

The extra processes are not necessarily a problem, but the extra processes using lots of memory and CPU are. Can you get a trace when the machine is in this state? The ideal state would be with just about:blank open so that we know that any memory and CPU usage is excessive. A screenshot of Chrome's task manager would also be helpful so we know for sure which renderer process is being used for about:blank.

Either a chrome://tracing trace or an ETW trace (https://tinyurl.com/etwtracing) will do the job, although I've had better luck with ETW tracing.

I agree that there is no reason to suspect enable-offline-auto-reload - that is just a command-line switch to happens to be on the processes. That doesn't indicate that it is involved.

I have attached another screenshot.

How would you like myself to send over the ETW Tracing. It is above 10MB?

Deleted: Foundation_ChromeTaskManager.PNG 54.0 KB

	Foundation_ChromeTaskManager.PNG 54.0 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

If you can share the Chrome trace with brucedawson@chromium.org using drive.google.com then I can take a look. The more context you give about when you recorded the trace (how long after launching Chrome) and what you did while the trace was being recorded the better.

Just shared them with you. 

Regarding the traces. I started the trace and then launched Google Chrome within 5 seconds. I then browsed to about:blank. After I let the trace run for 20-30 seconds before stopping. 

Let me know if you need anything further or have any additional questions. 

Retitling bug, otherwise it is difficult to remember what issue is being discussed

Unfortunately the traces didn't quite work. I see 203 chrome.exe, 21 copies of dwm.exe, etc. I assume that this means that there were ~21 users logged in to one machine.

The 203 chrome processes appear to come from 18 different browser processes. Most of them don't use very much CPU time - a couple of seconds at most - but the cumulative effect of a total of 601 processes running, many of them actively, means that the system is overwhelmed. The five CPUs are 100% busy most of the time.

It looks like the trace was recorded to circular memory buffers. This is a useful option but on a busy system like this it means that only a very short interval may end up being recorded. In this case I only got full data for 6.3 s in the first trace and 10.6 s in the second trace.

Ideally I need a trace that just has a single instance of Chrome's browser process running. Since that probably isn't possible then I need to know which browser process is the one that was just launched, and which renderer process is associated with about:blank.

I also needed a trace that isn't truncated. This can be obtained by using the "Tracing to file" mode of UIforETW instead of "Circular buffer tracing". Sometimes this will lead to lost ETW events. If so then just try again.

The methodology of starting tracing, then launching Chrome (once tracing has fully started) and then tracing for 20-30 seconds sounds perfect and should work well with "Tracing to file" and knowing the PID of the browser-process and renderer-process of interest.

Just updated my drive with the new trace and screenshot.

I'm confused by the trace and the screenshot. The screenshot shows the browser process with PID of 14760, about:blank with 7920. I extracted the process tree for 14760 and it is as shown:

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe (14760) - 9 processes
    browser     : 14760 
    crashpad    : 12724 
    extension   : 11260 
    gpu-process : 7296 16908 
    renderer    : 8488 15524 
    utility     : 12208 
    watcher     : 9320 

Notably missing is any sign of PID 7920. In fact I can't find that PID anywhere, in any Chrome processes, or any other processes, in the entire trace. So that's weird. I created another summary that shows context switches and CPU usage for that process tree:

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe (14760) - 31935 context switches, 12688.58 ms CPU, 9 processes
    browser     : total -  17395 context switches,  7944.13 ms CPU
        14760 -  17395 context switches,  7944.13 ms CPU
    crashpad    : total -    130 context switches,   190.30 ms CPU
        12724 -    130 context switches,   190.30 ms CPU
    extension   : total -   1781 context switches,   658.11 ms CPU
        11260 -   1781 context switches,   658.11 ms CPU
    gpu-process : total -   7382 context switches,  1546.29 ms CPU
         7296 -    689 context switches,   548.88 ms CPU
        16908 -   6693 context switches,   997.40 ms CPU
    renderer    : total -   4470 context switches,  1465.03 ms CPU
         8488 -   3694 context switches,  1086.51 ms CPU
        15524 -    776 context switches,   378.52 ms CPU
    utility     : total -    638 context switches,   687.04 ms CPU
        12208 -    638 context switches,   687.04 ms CPU
    watcher     : total -    139 context switches,   197.68 ms CPU
         9320 -    139 context switches,   197.68 ms CPU

Nothing clearly anomalous sticks out.

I then stepped back to look at all chrome.exe processes. There are 85 of them in the latest trace. 59 of those are renderer processes, and of those 51 have the --enable-offline-auto-reload flag set.

Most of the Chrome browser processes in the trace have very modest numbers of processes - by-design numbers. All have 7-12 processes, with one having 17. All have 2-4 renderer processes with one having ten. Whether this is completely normal or not depends on how many tabs each user has open, which I can't see, but I see no sign of odd behavior.

Note that the CPU usage numbers in the previous comment are from the 68 s of that Chrome instance that were recorded, for an average utilization of 20% of a core, or 4% of the machine, which seems pretty reasonable for a trace that covers Chrome startup.

Let's go back to the original bug report:

> Found -enable-offline-auto-reload using 5 additional processes using
> anywhere from 5-25% CPU usage and 5-10% RAM usage per Chrome instance open.

I have seen no evidence that -enable-offline-auto-reload is relevant. It is passed to most renderer processes in the trace and there is no reason to believe that it is a problem

So we have "5 additional processes using anywhere from 5-25% CPU usage" - but is that a problem? With 10-20 users on this machine running Chrome it is normal and expected that some users will have multiple tabs using multiple processes and using CPU time. On my laptop I currently have 22 chrome processes for nine tabs and various extensions, so "5 additional" is likely normal and expected. How much CPU time they use depends mostly on the pages I am browsing.

There are two possibilities here:
1) There is no problem. There is just a lot of CPU usage because ~10-20 users are sharing five CPUs and browsing to multiple sites.
2) There is a problem but it is not well characterized. In the original screenshot a renderer process is shown using CPU time. What user is that associated with? What page is that associated with? How is it known that that process is "additional" and that the CPU usage is excessive?


I think that the first possibility is correct. If it is actually the second possibility then we need more information in order to understand what the actual problem is so that we can investigate it.

Note also that chrome process 8488, a child of the 14760 browser process, has the --enable-offline-auto-reload flag specified, and yet that browser process does not have extra processes. This is further evidence that there is, in fact, no problem with that flag.

I think Chrome is working as intended.