100% CPU load in chrome/firefox #2375
Comments
|
hi @apollovy! Would it be possible for you to use chrome or FF's performance tabs to record a short profile and upload that here so we could inspect? Or is there any other information you could provide to help me reproduce this? (do the pages in question have a higher than average amount of data displayed in them?) (Thanks for disabling plugins, we've seen this in the past be caused by react development browser plugins like react-sight ) |
|
Hi, @MaxBittker. Sorry for a little bit long delay. |
|
i definitely believe that it happened - we've had such issues in the past. If you can get more information I'd love to fix this |
|
happy to re-open this if anyone has information |
|
This isn't really helpful, but I'll provide the info as much as I can. This was happening on a page with a relatively deep React tree. The CPU usage would shoot up to 150% and would not go down anymore, and pausing the scripts shows a breakpoint in Everything I do in the DOM becomes painfully slow, including clicking on things or moving the cursor in an input. Doing a performance profile shows that the DOM is being painted slowly.
The worse part is this happens randomly so I don't have any concrete replication steps. I'll provide more info if I discover anything else. |
|
@carlo-cogentlabs I have a suspicion (not confirmed yet, as it's very hard to repro this behavior) that it may have something to do with serializing dom nodes in order to show them in breadcrumbs. If you'd do any more testing and stumble upon this issue, could you set a breakpoint inside this |
|
@kamilogorek sure! I'll return to this bug tomorrow and post whatever I find here. thanks for looking into this. |
|
@kamilogorek unfortunately, I could not replicate the issue after trying for some time. I'll add the breakpoint in the line you provided and keep you posted should this ever occur again. |
|
@kamilogorek I was able to replicate the issue after about 2 weeks, but when adding a breakpoint to I found a lead, but it's not related to sentry. I was using a debugging extension in Chrome called React-Sight, and it was the one creating event listeners and DOM nodes faster than the GC can handle it. The DOM nodes, JS heap size, and event listeners shot up this much:
Surprisingly, the more updates that happened after the page starts to crawl, the easier it is to replicate the performance issue, and every update in React seems to create almost exponentially more nodes and listeners than before. It ended up showing an error in my console: where I'll still be looking into this just in case there's any correlation and will report it to React-Sight once I prove that it's really the extension that's causing it. For now I'd like to apologize for possibly reporting a false negative. I'll keep updating this thread just in case. |
|
Closing as this appears to have gone stale and there haven't been additional reports in the last couple months of this issue. |
|
I have the same issue still. I am rendering a fairly long dom tree of a table grid. I removed everything from the onclick event, except a console.log. When I just log out a 'hello world', everything is fine. But when I try to do anything with the event itself (even logging doesn't work) the CPU goes up to over 100 and the browser eventually breaks down after a couple of minutes hinting the
Hope that helps? EDIT: private handleRowClick = id => evt => {
console.log(Object.keys(evt));
Object.keys(evt).forEach(function(key, index) {
if (~['_targetInst', '_dispatchInstances', 'target', 'currentTarget'].indexOf(key)) {
console.log(key, ' at position ', index, ' is going to bust your cpu');
} else {
console.log(key, evt[key]);
}
});
};CPU doesn't spike at all and console is directly populated (except for '_targetInst', '_dispatchInstances', 'target', 'currentTarget' - where it still breaks). |
|
Hi It seems that I have some related performance issues with sentry browser. Is it normal that the sentryWrapped function is being called infinitely on my webpage ? You can test it on https://lacollection.airfrance.fr/fr-FR/listing?strategy=navigationFirst
It randomly freezes my listing page I'm using ABTASTY for ab test which script has continuous activities on my page :
The function below from ab tasty script is being called infinitely. For some reasons, this also triggers sentryWrapped function infinitely which may results some performance issues. Do you have some inputs regarding this case ? Why the sentryWrapped function is being called ? Best regards |
|
I'm also having this issue in Firefox Here is a link to a Firefox profiler export (it's like 20MiB of JSON). In the middle of the profile I temporarily switch away from the tab, and then back again. |
|
Hi guys, have you found fixes for this? We have a map with zillions of data freezing when we switch back and forth between tabs. The |
|
@eric-burel if you are using CDN, you can filter these frames to see where they originally point to - https://docs.sentry.io/platforms/javascript/troubleshooting/#instrumentjs-line-numbers-for-console-log-statements If that wont help, you can disable specific integrations to see what's the main culprit. Integrations that wrap APIs are called Sentry.init({
// ...
integrations: function(integrations) {
// integrations will be all default integrations
return integrations.filter(function(integration) {
return integration.name !== "TryCatch";
});
},
});or you can disable specific wraps through integration options (this is all turned on, which is default) Sentry.init({
integrations: [
new Sentry.Integrations.TryCatch({
setTimeout: true,
setInterval: true,
requestAnimationFrame: true,
XMLHttpRequest: true,
eventTarget: true
}),
new Sentry.Integrations.Breadcrumbs({
console: true,
dom: true,
fetch: true,
history: true,
sentry: true,
xhr: true
})
]
}); |
Macbook Pro Early 2011
OS X 10.11.6 (15G19009)
Chrome 65.0.3325.162 / Firefox 58.0.2 / FIrefox 59.0.2
When going to issues list page or a particular issue page, 100% CPU per tab is consumed, even in incognito mode with all the plugins disabled.
sentry.io
Nope
(Sorry for some Russian, but it's CPU time >100%, trust me 😇)
Nope
The text was updated successfully, but these errors were encountered: