I was able to install a new graylog server into a VM using these instructions:
http://docs.graylog.org/en/latest/pages/installation/os/ubuntu.html

Then in that VM, I downloaded chrome stable, beta, and unstable (58, 59, 60).  Only in version 59 (beta) did the problem reproduce.  So if this a regression, it might have been fixed in version 60?  If so, I'd love to get whatever fix that was backported to version 59, but I'm not sure the best way to narrow down what it was.

Let me know if you need anything more from me for machine specs or anything like that.

Some more information was added by another user (STRML) in the github issue I made in graylog.

https://github.com/Graylog2/graylog2-server/issues/3814#issuecomment-301782316

One excerpt from his comments:

"Digging through the trace, it appears to be in a Microtask loop. There may be a bug in 59 that executes microtasks synchronously, so if one is scheduled inside another it will busyloop all day."

Now that chrome 59 is now on stable, my whole team is seeing this issue now.  They are on macs, so it's not Linux specific like the OS list in the bug suggests.  I don't have permissions to edit that portion of the bug so could someone else do so?

Also is there any news on why this is fixed in chrome 60 (or was in my testing).  Is a backport a possibility?

This appears to be related to the use of TLS.

I've set up a test server that demonstrates the issue (log in with `admin:admin`)

http://graylog.strml.net/dashboards , when idle, does not use 100% CPU.

https://graylog.strml.net/dashboards (note TLS), does.

I've reproduced it consistently with http. Don't have a publicly-accessible reproducer, though.

I can reproduce that with Chrome 59.0.3071.86 on Ubuntu 16.04 LTS using my local Graylog development setup. (I am a developer in the Graylog team)

The Graylog web interface is running several background jobs using the setInterval() JavaScript function. If I disable all of those background jobs, the high CPU issue doesn't show up when I switch to a different browser tab. Once I enable only one of those setInterval() calls, the issue shows up again.

I found a way to make the high CPU usage stop by opening a specific HTML select dropdown on the Graylog search page. When I opened that dropdown, I can switch to a different tab and the CPU usage stays at 0, even with all background setIterval() jobs running. No idea why that fixes it. :)

Please find the attached screen-capture.gif file which shows the issue and how opening the dropdown "fixes" it.

Once I opened the dropdown, the high CPU usage never shows up again for the lifetime of that browser tab. Even if I reload the Graylog web app with ctrl+shift+r I cannot reproduce the issue again. Only when opening a new browser tab it will show up again.

I hope that helps. Please let me know if you need more information.

Deleted: screen-capture.gif 564 KB

	screen-capture.gif 564 KB View Download

I forgot a detail in my previous comment.

The background setInterval() jobs are running HTTP requests against the Graylog server API and update the page if some state changes.

I created a simple setInterval() job which only logs to the console and that didn't trigger the high CPU usage when switching to a different browser tab.

Sorry to hear about the issue, and thank you for all the detailed reporting, folks. This makes things a lot easier!

+Chris, it sounds like the net stack may be the culprit here. See some references to HTTP requests and TLS above, and it in the trace it appears that the high CPU is being triggered by an XHR (consistent with the above description). I assume there's some priority inversion going on here when we're switching tabs... so also +Sami and +Alexander in case this is a scheduling issue.

That it's attributed to the Tab, rather than the Browser process, implies its renderer side. Removing Internals>Network>SSL because of that.

Based on the trace it looks like this mojo function is continually posting itself:

https://cs.chromium.org/chromium/src/content/common/message_port.cc?rcl=2febb9832367123799f3e553274c4449f91a5634&l=200

Could someone more familiar with that code have a look?

AFAICT this is only possible if a MessagePort onmessage handler triggers itself, e.g.:

  let channel = new MessageChannel;
  channel.port2.onmessage = () => channel.port1.postMessage("hai");
  channel.port2.start();
  channel.port1.postMessage("hai");

If this is fixed in M60 I suppose (wild guess) it may be due to task scheduling changes. The MessagePort impl hasn't been touched since M59.

I just got an update to Chrome 59.0.3071.104 on Ubuntu 16.04 LTS but the problem still persists. I didn't expect it to be fixed, so this is just a FYI. :)

I am suspecting this is something similar issues#733469 and  733469 , currently we are planning to revert the patch in M59.

I just updated to Chrome 59.0.3071.109 on Ubuntu 16.04 LTS and I don't see the problem anymore! :)

Good work and thank you very much!

Verified fixed here as well. Shutting down the Graylog server. Thanks!

Re #20: I'd like to investigate this problem further to avoid repeating it again. Could you keep the server alive for an extra couple of weeks?