I’m experiencing high CPU usage with any Octopus page open in the browser. The same happens in Edge (latest Win 10) and Chrome (latest). When it occurs in Edge, Task Manager indicates the tab consuming a constant ~25% of CPU. In Chrome, the built-in Chrome Task Manager shows the tab consuming a constant 90-100% of CPU. It has become so bad that I have to close all Octopus tabs when I’m not using it.
It doesn’t matter what page the tab is viewing – even the top-level Configuration page for example. I don’t have to interact with the page at all for it to continue the same CPU utilization.
We’re currently on v2018.11.3 on-prem, but this has been happening for (at least) several months through multiple versions.
It doesn’t happen immediately, but seems to happen after maybe 45 minutes to an hour. I opened Octopus this morning, randomly clicked around for a bit, left it for an hour, came back and clicked around more, and it reached 100% in Chrome.
It isn’t making any abnormal or frequent network requests. It appears to be running script code, but for some reason Chrome doesn’t identify a specific method. There are a bunch of calls into webpack:///./app/components/Sticky/Sticky.tsx, but I’m not sure that’s the culprit.
If it is you would be seeing requests that are unrelated to the page you are currently browsing. A good way to tell for sure would be to capture your browser’s network trace while you are experiencing heavy CPU usage and send it to support@octopus.com.
When the high CPU usage is occurring, the F12 tools in both Edge and Chrome show virtually no HTTP requests. There is just an occasional request to /serverstatus. It does not appear related to that issue.
I recorded a performance session in Edge for just about 5 seconds, and in that short time 10’s of thousands of timer events were recorded calling the same two functions.
Sticky.tsx:41 (by far the most common)
LinearProgress.js:155 and 167
After restarting Edge and opening Octopus again, the CPU issue is gone. Recording another performance session for about 7 seconds still revealed thousands of calls into Sticky.tsx:41, but an order of magnitude fewer than in the previous session.
