Summary
Track runtime-specific memory metrics during benchmarks, beyond the process-level RSS already provided by SystemMonitor. This enables detection of memory leaks, GC pressure, and heap growth during soak tests.
Current Behavior
SystemMonitor tracks process-level RSS via /proc/<pid>/status, which shows total physical memory but doesn't break down heap vs off-heap, GC pauses, or runtime-internal memory usage.
Proposed Behavior
Each engine should emit runtime-specific memory metrics alongside existing benchmark metrics. This is especially valuable when combined with interval reporting for soak test time-series analysis.
Implementation Notes
- Java: JVM heap via JMX (heap used/committed/max, GC pause count and duration)
- C#: .NET GC heap, working set, committed bytes
- Node.js:
process.memoryUsage() (heap used, RSS, external/array buffers)
- Go:
runtime.MemStats (heap alloc, sys, GC pauses)
- Python/Ruby/PHP: less relevant (no managed heap), process RSS from SystemMonitor is likely sufficient
- For GLIDE specifically, native memory from the Rust core is allocated outside the managed heap, covered by RSS from SystemMonitor
Note
Copied from ikolomi/resp-bench#18.
Originally opened by @jeremyprime on
2026-04-09T18:12:03Z.Summary
Track runtime-specific memory metrics during benchmarks, beyond the process-level RSS already provided by SystemMonitor. This enables detection of memory leaks, GC pressure, and heap growth during soak tests.
Current Behavior
SystemMonitor tracks process-level RSS via
/proc/<pid>/status, which shows total physical memory but doesn't break down heap vs off-heap, GC pauses, or runtime-internal memory usage.Proposed Behavior
Each engine should emit runtime-specific memory metrics alongside existing benchmark metrics. This is especially valuable when combined with interval reporting for soak test time-series analysis.
Implementation Notes
process.memoryUsage()(heap used, RSS, external/array buffers)runtime.MemStats(heap alloc, sys, GC pauses)