@flakpyro said in backup mail report says INTERRUPTED but it's not ?:
@olivierlambert Using the prebuilt XOA appliance which reports:
[08:39 23] xoa@xoa:~$ node --version
v20.18.3
@majorp93 @pilow Can you please capture some heap snapshots from during backup runs of XOA via NodeJS?
Then compare them to each other, they need to be in the following order:-
Snapshot before backup
Snapshot following first backup
Snapshot following second backup
Snapshot following third backup
Snapshot following subsequent backups to get to Node.js OOM (or as close as you’re willing to risk)
These will require that XOA (or XOCE) is started with Node.js heap snapshots enabled. Then open in a Chromium based browser the following url:-
chrome://inspect
The above URL will require using the browser’s DevTools features!
Another option is to integrate and enable use of Clinic.js (clinic heapprofiler), or configure node to use node-heapdump when it reaches a threshold amount.
Once your got those heap dumps your looking for the following:-
Object types that grow massively between the snapshots.
Large arrays or maps of backup-related objects (VMs, snapshots, jobs, tasks, etc.).
Retained objects whose “retainers” point to long-lived structures (global, caches, singletons).
These will likely help to pin down what and where in the backup code, the memory leak is located.
Once have these a heap snapshot diff showing which object type (or types) growing by a stated size per backup will finally help the Vates developers fix this issue.
@florent I left the above for the original reporters of the memory leak issue, and/or yourselves.
