An investigation into unexplained memory growth during MariaDB TPROC-C stored procedure benchmark runs traced the leak to HammerDB's benchmarking tool itself, not MariaDB. HammerDB 5.0's xtprof time profiler collected unlimited samples per virtual user, causing unbounded RSS growth. HammerDB 6.0 introduces an xt_reservoir setting (default 10000 samples) that caps sample collection, keeping memory flat around ~740 MB. The Test Automation Framework (TAF) was updated to default to HammerDB 6.0, add an improved RSS logging script, and retain HammerDB 5.0 for reproducibility until the next release.
Questions this post answers
Why does HammerDB 5.0 keep growing in memory usage during long TPROC-C stored procedure runs?
HammerDB 5.0's xtprof time profiler does not limit the number of samples it collects per virtual user, so memory usage grows continuously as the benchmark runs. This is not a MariaDB memory leak; RSS for the MariaDB server itself stays flat during the same workload, while HammerDB's own process memory keeps climbing. Anyone chasing benchmark memory growth can compare notes on tool-side leaks like this on daily.dev.
What is the xt_reservoir setting in HammerDB 6.0 and what value should I use?
xt_reservoir is a HammerDB 6.0 setting in the timeprofile block of generic.xml that caps how many samples the xtprof profiler collects per virtual user, defaulting to 10000. Leaving it at 10000 keeps memory stable around 740 MB, while setting it to 0 restores the old HammerDB 5.0 behavior of unlimited sampling and unbounded memory growth. Teams tuning HammerDB configs for stable long-duration benchmarks can track settings like this on daily.dev.
How can I monitor RSS memory usage per process during long-duration database benchmark runs?
A custom rssLogger.sh script can track RSS per process by resolving and printing the process name (such as mariadbd or hammerdbcli), adding timestamped entries, and printing the PID alongside process name on every log line into an auto-named log file. Each monitored process needs its own instance of the script running in parallel. Engineers building benchmark tooling can find practical monitoring scripts like this via daily.dev.