pm2 max_memory_restart metric consistency across container cgroups

In deployments where pm2's max_memory_restart is used to guard against memory leaks, the threshold value is specified in megabytes but pm2's internal memory reporting may not align with the host operating system's RSS or container cgroup limits. This creates ambiguity about whether the restart trigger reflects actual process memory, aggregated container memory, or a pm2‑specific metric.

Furthermore, in clustered mode with -i max, each worker respects its individual max_memory_restart limit while the master process does not enforce a global cap, and the documentation offers no guidance on how memory fragmentation or periodic garbage collection affects trigger reliability.

Does pm2's max_memory_restart threshold operate on RSS as reported by the Node.js process, on the container's cgroup max, or on a hybrid metric? How does the restart behavior change when the underlying container's memory limit is set close to the configured threshold? What is the smallest sustained memory increase that reliably triggers a restart without being masked by transient allocations or pm2's own sampling interval?