Diagnosing High Desktop CPU Usage

io.Connect Desktop
,
1

Below are some tips on how to track down the causes of high CPU usage and determine whether it’s caused by an app(s), platform misconfiguration, Chromium/Electron, or simply an under-resourced machine.

How do I see per-application CPU usage?

  • From the io.Connect UI. Right-click the tray icon, then select Applications.

  • From the logs. The application log contains system-level and per-application CPU and memory figures. Check forperf-log or proc-log.

  • From Task Manager. Take the PID for the application from the logs and monitor the corresponding process in Task Manager.

If you have io.Insights deployed, the app_cpu and app_memory metrics give you the same breakdown over time. See the MetricType reference and A Complete Walkthrough of the Grafana Observability Dashboard.

How do I tell whether a given application’s CPU usage is abnormal?

Compare against the rolled log files. An app running at 5% may not seem high, but if it’s usually consuming 1%, it’s worth checking.

The application is idle, but DevTools shows continuous “Task” entries with no detail. How do I find out what they are?

Use the Performance profiling panel in Chrome DevTools:

  1. Open DevTools.
  2. Go to the Performance tab.
  3. Click Record (the round button on the left).
  4. Let the application run for a while, then stop recording.
  5. In the Summary view, you’ll see a breakdown by System (self), System (children), Scripting, etc.
  6. To examine what exactly triggers the “Task” events, switch to the Call Tree or Bottom-up tabs next to Summary.

Capture evidence at the moment of the freeze

A dump taken while the UI is actually frozen tells you far more than logs sampled before or after it.

Capture before reloading the Workspace - reloading clears the state.

From the frozen tab, either:

  • A DevTools Performance profile, or a JavaScript stack.
  • A renderer process dump - Task Manager → Details → the io.Connect renderer process for that tab → Create dump file. Identifying the right renderer usually means mapping the PID first; the logs are the easiest place to get it.

If a particular app has previously gone unresponsive on its own, start with that one.

io.Connect Desktop also captures JavaScript call stacks automatically when apps become unresponsive, on version 9.9 and later, see Unresponsive Apps in io.Connect Desktop stack tracing.

Why io.Connect appears to consume a large share of CPU

io.Connect Desktop hosts your applications, each in its own process. When the reported figure for io.Connect is high, the first step is to break it down per application before investigating the platform itself. Sometimes you’ll see a machine running at 80 or 90% percent, but the per-application breakdown showing that there are 20 running apps each consuming 3-5% causing high combined usage, instead of a single runaway process.

Few additional notes

  • Two things to know when reading perf-log:
    • percentCPUUsage is what tells you whether a process is busy now. A cumulative CPU figure is a running total, not current load - a large cumulative value alongside percentCPUUsage: 0 means the process is idle at that sample. An early analysis in one investigation leaned on the cumulative number and pointed at the wrong process.
    • A core pinned near 100% while overall CPU is low does not tell you which process owns it. In one investigation such a core turned out to be busy continuously, including when nothing was frozen, and to belong to an unrelated background process. Check a saturated core against periods when the symptom is absent before treating it as relevant.
  • Timeouts under load are a symptom, not a cause. During sustained high CPU, operations that normally complete quickly can time out and log errors - for example Error while preparing web group ... Could not load web group, or The operation has timed out. These appear because the machine is saturated. Treat them as evidence of the load, not as its origin.
  • Rule things out against the rolled logs. When investigating a particular incident check if warnings are also present in the rolled logs during periods of normal CPU usage.
  • Gilding was removed in io.Connect Desktop 10.0. Older diagnostic procedures include checking the gilding log. As of io.Connect Desktop 10.0, the platform “no longer has a gilding executable file and a gilding.json configuration file respectively”, so diagnostic procedures that depend on the gilding process no longer apply on 10.x.