Let me know if there's any additional information I could provide to help triage this.

Tested the issue on chrome reported version 67.0.3396.79 using Windows 10 with steps mentioned below:
1) Launched chrome version# 67.0.3396.62 and updated it to 67.0.3396.79
2) Opened Google chrome Task manager and observed CPU usage for Browser as 7.7

@Reporter: Please find the attached screenshot for your reference and provide your feedback on it, try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists.

Thanks!

Deleted: 850893.PNG 127 KB

	850893.PNG 127 KB View Download

Hmm, I suspected it was either due to an extension, or one of the 260 tabs I have open. I disabled all extension and restarted and it's still there, so that leaves the tabs.

I tried Chrome Nightly and initially it was ok, but after installing some extensions and opening a few (less than 40) tabs it came back.

One tab had Flash running, the others were mostly Confluence pages that you won't be able to view.

I've also updated Chrome to:
Version 67.0.3396.87 (Official Build) (64-bit)

I'll keep trying to narrow it down...

Thanks for testing.

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

Everyone in our organization is having the same issue with Chrome instantly utilizing 100% CPU once launched.  This is happening on our Windows 7 devices with 32-bit version of Chrome

It doesn't sound like Site Isolation would be the cause of this, but just in case, can you try temporarily disabling it using https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Diagnosing-Issues to see if the problem goes away (and comes back when you re-enable)?  Would be helpful for narrowing down potential causes.

Issue 852542 has been merged into this issue.

+govind@ for awareness based on reports in #6 and issue 852542.

pbommana@, could you pls try to repro and bisect if possible?

Similar bug reported for Mac on Chrome M67 stable version 67.0.3396.62 was fixed in 67.0.3396.79 - https://bugs.chromium.org/p/chromium/issues/detail?id=848210#c64. 
But seeing this issue on Windows, Chrome version 67.0.3396.79.

+horo@ based on above comment.

Please let us know if CPU usage spike's only on Chrome launch and get's back to normal after few seconds/a minute of Chrome launch or not.

If it's just on Chrome launch,I am able to reproduce the issue where browser process takes ~50-60% of CPU, but drops back to less then 10% CPU usage in in few seconds and then after few more seconds it's around 4-5% CPU usage.

jackalberto@ is there any way we can know the list of extensions or details from  Client to better understand the bug please.

I am the client that reported this same issue that was merged (852542). I have confirmed that site isolation was already disabled in our environment.

The extensions currently on my browser are:

Adobe Acrobat
Cisco Webex Extension
Google Docs Offline
Docs

I'll attempt to remove those one by one to see if the problem still exists and update with that info.

FYI, the one difference to note is this original bug appears to be reported on Win 10, 64-bit Chrome. We have not had any issues with the 64-bit version, and even fixed the issue on some of our PC's by pushing the 64-bit version instead of 32-bit (if the OS could support it). The remaining PCs with the issue (~810 of them) are 32-Bit Windows 7, so we have to use the 32-bit version of Chrome.

I removed the 4 extensions installs one by one with a Chrome restart in-between. The removal of Google Docs Offline and Docs had no impact. Removing Adobe seemed to lower the CPU usage slightly, as it in only pegged at 100% most of the time instead of all. Removing Cisco WebEx initially showed CPU only spiking to 100% initially, then lowering to 70%, but then went back to 100% constant again while just trying to load one webpage.

So the issue still exists with no plugins installed at all.

Whenever a webpage is loading this is the behavior.

Deleted: chromecpu.png 114 KB

	chromecpu.png 114 KB View Download

Replying to #c13 https://bugs.chromium.org/p/chromium/issues/detail?id=850893#c13

It's not just during launch, it is still happening hours after launch. I can even go into Windows task manager and kill every render process (because some aren't listed in Chrome's Task manager) and it still continues.

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

Charlie - will a Chrome trace pick up enough information about CPU usage to help debug?

Someone experiencing this should run a trace to get more information:
https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

There are two different issues at hand.

sam: Please remove the "memory footprint" column from task manager and close/reopen it - see if CPU usage has gone down. There's a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=851712 where the computation of that column is more expensive than it should be.

markis: Please obtain a chrome trace as per c#21.

Attaching trace as requested.

Removing the memory footprint column has no effect.

It could be 848210, how could I confirm that?

Trace attached

Deleted: trace_850893-sam-hasler.json.gz 526 KB

trace_850893-sam-hasler.json.gz 526 KB Download

Did the trace give any helpful information? Do you need me to capture another one?

markis97: I unduped your bug - it's a different issue
sam: Look like sync is spinning non-stop.

tschumann: See trace in c#25.

Thank you for the update. Though it does look like bakersco does have the same issue I did. Not sure if there is a way to link them to my bug.

Sam: The profile indeed shows sync using up quite some CPU while downloading updates from the sync server; and I see 8 batches of downloads from sync.

To better understand what's going on, I have a few more questions:
1) how long do the CPU spikes last?
2) are there at specific events (e.g. start-up, or happening periodically)?
3) can you provide a screenshot of about://sync-internals

It's constant as far as I can tell.

I've attached 4 screenshots. A few things I noticed:

from screenshot #1
 - In Sync-internals the "Sync Protocol log" box is constantly having "GetUpdate" entries added to it. NB that happens even if I disable "sync everything".
 - I have over 200,000 bookmarks, but Sync internals says 0. I've previously seen the correct amount displayed on sync-internals.

from screenshot #2
 - The "Total entries" "live entries" columns sometimes flash up as all "null"

from screenshots #3 and #4
d) Also even with "Sync Everything" disabled, the main settings page says that Sync is On.

[1] Chrome-67-cpu-sync-internals.png
[2] Chrome-67-cpu-sync-internals-null.png
[3] Chrome-67-cpu-advanced-sync-settings.png
[4] Chrome-67-cpu-settings.png

Deleted: Chrome-67-cpu-sync-internals.png 144 KB

	Chrome-67-cpu-sync-internals.png 144 KB View Download

Deleted: Chrome-67-cpu-sync-internals-null.png 196 KB

	Chrome-67-cpu-sync-internals-null.png 196 KB View Download

Deleted: Chrome-67-cpu-advanced-sync-settings.png 41.5 KB

	Chrome-67-cpu-advanced-sync-settings.png 41.5 KB View Download

Deleted: Chrome-67-cpu-settings.png 4.3 KB

	Chrome-67-cpu-settings.png 4.3 KB View Download

Ok, I might have overstated how many bookmarks I have, it's 26,324.

It's an hour or so later and sync-internals is now showing values in the Type Info section. See attachment.

Deleted: Chrome-67-cpu-sync-internals-2.png 146 KB

	Chrome-67-cpu-sync-internals-2.png 146 KB View Download

Also, I can Sign Out of chrome and I STILL see repeating "Get Update" request/responses. Is that normal?

I don't see this on Chrome Nightly, although I've never signed in to Nightly.

interesting, it keeps constant nudges of the "device info" data type.
mastiz: could that be related to the fix of fixing the synced device name?

sam:
-- I'd like to inspect server side logs of these requests to figure out what the device info updates are. As this requires access to your personal data (everything you sync is considered personal), I would need your approval to do so. Assuming you use "sam.hasler@gmail.com" to sync data with ChromeSync, could you update the bug with a confirmation? (and if you're using a different sync account, please let me know that account and update the bug with that account).

-- if you're uncomfortable with this, we can also try to figure it out without server access. The first step would be to open about://sync-internals and click on the "Sync Node Browser" at the top. On the left you'll find a folder named "Device Info". A screenshot of that would help; possibly with the data of the device you're accessing chrome from (especially if you can see any data changing in there).

Thanks!

Taking a look. Wrt the device-name fix for crbug.com/314681, that was SESSIONS, not DEVICE_INFO. 

Lets try this first; if it doesn't help let me know and I'll approve looking at the server logs.

(I've redacted the computer name in 3 places as it's also a DELL service tag.)


Title	Device Info
ID	null
Modification Time	null
Parent	r
Is Folder	true
Type	Device Info
External ID	null
{
  "IS_DIR": true,
  "NON_UNIQUE_NAME": "Device Info",
  "PARENT_ID": "r",
  "UNIQUE_SERVER_TAG": "Device Info",
  "modelType": "Device Info"
}



Title	[REDACTED]
ID	s154522_GcfaLg02io7gkFGJtuzm48L7rJc=
Modification Time	null
Parent	
Is Folder	null
Type	Device Info
External ID	null
{
  "CLIENT_TAG_HASH": "",
  "CREATION_TIME": "Thursday, 1 January 1970 at 01:00:00",
  "ID": "s154522_GcfaLg02io7gkFGJtuzm48L7rJc=",
  "IS_FOLDER": false,
  "MODIFICATION_TIME": "Thursday, 1 January 1970 at 01:00:00",
  "NON_UNIQUE_NAME": "[REDACTED]",
  "PARENT_ID": "",
  "SPECIFICS": {
    "device_info": {
      "cache_guid": "HJgzMG5SmBL7UuJJ80Tf1g==",
      "chrome_version": "67.0.3396.87",
      "client_name": "[REDACTED]",
      "device_type": "TYPE_WIN",
      "last_updated_timestamp": "1529408978233",
      "signin_scoped_device_id": "local_device",
      "sync_user_agent": "Chrome WIN 67.0.3396.87 (878cd31214ac27a3996927cd5c9c138b10c9fc8d-refs/branch-heads/3396@{#771}) channel(stable)"
    }
  },
  "UNIQUE_POSITION": "INVALID[]",
  "metadata": {
    "acked_sequence_number": "112",
    "client_tag_hash": "GcfaLg02io7gkFGJtuzm48L7rJc=",
    "creation_time": "1519141228937",
    "is_deleted": false,
    "modification_time": "1529408978233",
    "sequence_number": "112",
    "server_id": "154522_GcfaLg02io7gkFGJtuzm48L7rJc=",
    "server_version": "329238",
    "specifics_hash": "Nn0ahtef02pWqUFiOJU7e6vCUGQ="
  },
  "modelType": "Device Info"
}

So this is using "local sync" and not the Google hosted sync server.

Julian: Any idea what could be causing the client to constantly nudge for the DEVICE_INFO sync type?

Sam: Maybe we can get a few more details out of the request.
On about://sync-internals, there's Traffic Log tab. This lists all the recent requests, and more details if you click on the lower border line of an item (I attached an example screenshot). Can you click there for one of the GetUpdates requests (that says Nudged types: Device info) and copy the request data in here?

They all appear to be identical:

{
  "debug_info": {
    "cryptographer_has_pending_keys": false,
    "cryptographer_ready": true,
    "events": [
      {
        "sync_cycle_completed_event_info": {
          "caller_info": {
            "notifications_enabled": true,
            "source": "UNKNOWN"
          },
          "get_updates_origin": "GU_TRIGGER",
          "num_encryption_conflicts": "0",
          "num_hierarchy_conflicts": "0",
          "num_reflected_updates_downloaded": "0",
          "num_server_conflicts": "0",
          "num_updates_downloaded": "0"
        }
      },
      {
        "nudging_datatype": "154522"
      }
    ],
    "events_dropped": false
  },
  "get_updates": {
    "caller_info": {
      "notifications_enabled": true,
      "source": "LOCAL"
    },
    "create_mobile_bookmarks_folder": false,
    "fetch_folders": true,
    "from_progress_marker": [
      {
        "data_type_id": "154522",
        "get_update_triggers": {
          "client_dropped_hints": false,
          "datatype_refresh_nudges": "0",
          "invalidations_out_of_sync": false,
          "local_modification_nudges": "1"
        },
        "notification_hint": "",
        "token": "MzI5MjM4"
      },
      {
        "data_type_id": "194582",
        "get_update_triggers": {
          "client_dropped_hints": false,
          "datatype_refresh_nudges": "0",
          "invalidations_out_of_sync": false,
          "local_modification_nudges": "0"
        },
        "token": "MA=="
      },
      {
        "data_type_id": "202026",
        "get_update_triggers": {
          "client_dropped_hints": false,
          "datatype_refresh_nudges": "0",
          "invalidations_out_of_sync": false,
          "local_modification_nudges": "0"
        },
        "token": "NDk2MTI="
      },
      {
        "data_type_id": "47745",
        "get_update_triggers": {
          "client_dropped_hints": false,
          "datatype_refresh_nudges": "0",
          "invalidations_out_of_sync": false,
          "local_modification_nudges": "0"
        },
        "token": "NDk2MTM="
      },
      {
        "data_type_id": "161496",
        "get_update_triggers": {
          "client_dropped_hints": false,
          "datatype_refresh_nudges": "0",
          "invalidations_out_of_sync": false,
          "local_modification_nudges": "0"
        },
        "token": "MA=="
      }
    ],
    "get_updates_origin": "GU_TRIGGER",
    "need_encryption_key": false
  },
  "share": ""
}

Tentatively adding "ReleaseBlock-Stable" for M68. Please remove if needed.  

To be honest I don't know what is the device info type and guess it might be one of the unsyncable types.

Mikel do you know what this type is and is it new to recent Chrome versions?

The type has been around for a long time and we haven't recently made intentional changes there.

DeviceInfo syncs up basic information about the local device (name, version, etc.), we mostly use it to debug customer issues.

From the screenshot above it seems the local backend server is correctly replying that there are no updated to be pulled so it seems the client somehow insists on doing those requests every second for its own reason.

Agreed, and I cannot explain why that's the case, but somehow it affects local sync only. 

This might be interesting: If I'm reading the following from comment 37 correctly, the DeviceInfoSpecifics get-updates is a local_modification_nudge:
"""
    "from_progress_marker": [
      {
        "data_type_id": "154522",
        "get_update_triggers": {
          "client_dropped_hints": false,
          "datatype_refresh_nudges": "0",
          "invalidations_out_of_sync": false,
          "local_modification_nudges": "1"
        },
        "notification_hint": "",
        "token": "MzI5MjM4"
      },
"""

Mikel, do you know where that local modification nudge happens? (and any idea why it either doesn't go away or keeps nudging?)

Is this to do with https://developers.google.com/web/updates/2015/05/local-modifications

If I removed all Local Modifications (how can I find them) would it perhaps stop eating my CPU?

We’re seeing the same behavior in our environment. 64 bit build of .87 thus far is unaffected. 32 bit build of .87 shows high cpu, slow loading pages. Site isolation flag has no effect. Confirmed behavior w/ no added extensions loaded.

christopher, can you provide a screenshot of about://sync-internals ?
that would help us figuring out if it's related to the local sync server.

Thanks!

I tried to repro this on trunk Linux and couldn't.

pastarmovj@: Is this something you can repro? If yes, can we add browser tests (sync integration tests) for local sync? (We don't seem to have any).

I tried once on my dev machine with no success. Will try again tomorrow on a clean VM env.

Context: I'm a web developer that uses Dev Tools a lot.

Is it possible that you're unable to reproduce because the syncing is triggered by some condition that I've created via my use of dev tools?

Is there any particular operation in the dev tools that triggers the issue? I tried opening the dev tools on some random sites. Setting breakpoints, observing network requests etc. but nothing caused the issue described here.

I assumed from the reference to local_modification_nudge that it was to do with making local modifications.

Bulk update: M68 stable cut is scheduled for July 19th. This issue is marked as RB-Stable, so please take a look at it before. Thanks!

Any updates on this bug? I'm moving to M69.

Maybe related / caused-by  crbug.com/867929 

We have had Chrome roaming profiles enabled on our domain for some time now without incident, with the profile location being hosted on a network share.  Recently the server that hosts the profiles was getting slammed, and we noticed the chrome process on user PC's using a large amount of network bandwidth (like sustained bursts of 50MB/s).  It seems that Chrome is rewriting the profile.pb file over and over again-- as hitting F5 on the location of the file shows the file being 0kb one second, while large the next.  This repeats over and over endlessly.  Deleting the profile.pb doesn't help the issue, it just gets recreated and the problem continues  Users are using latest public version of Chrome.  This seems to be this bug at work

Deleted: Capture.JPG 208 KB

	Capture.JPG 208 KB View Download

pastarmovj@,
Friendly ping to get an update as it is marked as RB stable.
Thanks..!

M69 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.

We have too little information at this point about what is the cause of this issue. I would say we can remove the RB label as it is bad but apparently only affecting a very small set of users.

Mikel, do you have some suggestion how the users that report this can check if  crbug.com/867929  is indeed the culprit.

A potential fix is being discussed in crbug.com/871733, let me mark this bug as blocked by 871733.

It is hard to assess if this will fix this bug but it seems at least as a good start. I think we should punt it by one more release because merging the fix of 871733 into M69 seems to risky.

Punting to M70 based on comment #60.

pastarmovj@, Friendly ping to get update as it is marked as RBS.
Thanks..!

Let's remove the RBS for now. I will monitor the bug this one is blocked and request reevaluation if this is a solution to the issues observed when it has been foxed.

No updates here AFAIK, but we expect some progress in the blocked-on bug soon.

 Issue 916720  has been merged into this issue.