# Diagnosing Growing Main-Process Memory in io.Connect Desktop

**URL:** <https://community.interop.io/t/diagnosing-growing-main-process-memory-in-io-connect-desktop/669>\
**Category:** io.Connect Desktop\
**Tags:** logs, performance-tuning, Glue42\
**Created:** [August 25, 2026, 7:58am UTC](https://community.interop.io/t/diagnosing-growing-main-process-memory-in-io-connect-desktop/669 "2026-08-25T07:58:40Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![toni.petrov](https://yyz2.discourse-cdn.com/flex028/user_avatar/community.interop.io/toni.petrov/32/17_2.png) [@toni.petrov](https://community.interop.io/u/toni.petrov)\
**Post date:** [August 25, 2026, 7:58am UTC](https://community.interop.io/t/diagnosing-growing-main-process-memory-in-io-connect-desktop/669/1 "2026-08-25T07:58:40Z")

</div>

## Problem

The `main` (Electron browser) process of the container grows steadily across a working day. Memory does not return to its earlier level, and the running apps are eventually terminated abruptly.

The growth is visible in the `perf-log` entries written to the container log. Worth checking:

- `memoryKB` for the `Main` entry
- `external` and `heapUsed`

Below are few checks you can do:

## Check whether it is really the main process

Read `perf-log` for whether a figure is abnormal (see [Diagnosing High Desktop CPU Usage](https://community.interop.io/t/diagnosing-high-desktop-cpu-usage/663)): compare against the rolled logs, examine `memoryKB` per process and break the platform total down per app before investigating the platform itself. For log locations and rollover, see [Understanding logs in io.Connect](https://community.interop.io/t/understanding-logs-in-io-connect/36).

* * *

## Take a heap snapshot of the main process

You can capture a heap snapshot of the main process from the container UI:

1. Tray icon → **Diagnostics** → **Take heap snapshot**.
2. Take one snapshot at startup and a second one once memory usage has grown. Comparing two snapshots is far more useful than reading one.
3. Open the resulting file in **Chrome DevTools → Memory** tab to analyse it.

When you open a support ticket, the snapshot files can be attached to it for a better picture during investigation.

Clicking **Take heap snapshot** produces no dialog, no toast and no progress indicator. The snapshot is smply written in the user data folder for the current environment and region (confirmed in 9.10):

```auto
%LocalAppData%\interop.io\io.Connect Desktop\UserData\<ENV>-<REG>\<epoch-milliseconds>.heapsnapshot

```

> In the old Glue42 Enterprise 3.20 the file is in a `Tick42` folder under the user data path.

* * *

## Attach Chrome DevTools

Heap snapshots are point-in-time. If you can reproduce the growth on a machine you control, attaching DevTools gives you a live view.

**Main process (Node side)**

1. Pass `--inspect=9229` as a command line argument to the container executable.
2. In Chrome, open `chrome://inspect/`.
3. Click **“Open dedicated DevTools for Node”** , then add a connection to `localhost:9229`.
4. After closing the connection dialog, a remote target appears.
5. Click **“inspect”** to open DevTools and investigate memory usage and heap snapshots.

**App windows (renderer processes)**

1. Pass `--remote-debugging-port=9229` as a command line argument to the container executable.
2. Open `chrome://inspect/` in Chrome.
3. A list of all running applications appears.
4. Click **“inspect”** on any target to debug memory usage or take heap snapshots for that renderer process.

Check also [Developers \> Debugging](https://docs.interop.io/desktop/developers/debugging/index.html)

* * *

## Correlate with what changed

If an app was updated that may cause unexpected behaviour - track every tiny change, compare before/after performance and have an easy to revert plan. io.Insights can be used to easily compare performance after each update: [A Complete Walkthrough of the Grafana Observability Dashboard](https://community.interop.io/t/a-complete-walkthrough-of-the-grafana-observability-dashboard/573#p-969-platform-metrics-version-by-version-breakdown-3)