Memory consumption increasing running hammerdbcli on Windows

[sm-shaw]

Discussed in #763

^{Originally posted by filiptanic98 October 30, 2024}
Hello all,

I noticed that memory consumption is constantly increasing when running HammerDB TPCC benchmarks through hammerdbcli and using .tcl scripts.
My infrastructure consists of containers created inside of Azure VMs. From those containers I am targeting my MS SQL Server instance.
To run hammerdb from containers I use .tcl scripts and hammerdbcli.
I noticed that sometimes when I run TPCC I was getting out of memory errors in containers.
After that I investigated and found out it was correlated with the benchmark duration.
I continued my investigation and found out that memory usage of tclsh86t process is constantly increasing when benchmark is running.
I also tried reproducing this from outside container on my local machine and behavior is same.
I tried with running HammerDB from GUI (which runs wish86t.exe process) and there is no memory usage increase.
Image1 - reproduced issue on my local machine:

Image2 - shows constant memory increase for the container running inside kubectl environment:

Did someone encounter similar issues with hammerdbcli?

[sm-shaw]

I have done an initial investigation and the effect can be observed on all databases on both Linux and Windows with both GUI and CLI.

The cause is from the xtprof time profiling package, and therefore the increase in memory is to be expected.

Every time a stored procedure is called for every virtual user, the timing data is recorded in a virtual user independent array. When each virtual user is finished, the data is shared with the monitor virtual user that collects all the timing data and reports it.

The gathered data is deleted for each virtual user after sharing it, however some of the monitor virtual user dicts and thread shared variables are only reset on the next run. Therefore, we can free some memory by freeing these thread shared variables and dicts after the timings are reported, rather than at the start of a run.

However, the main memory increase during a run can be explained by HammerDB gathering the timings for every VU for every function call and storing it locally in an array, which is a relatively large amount of data.

Note that if the xtprof timer is not loaded (in the GUI or CLI) then timings are not gathered and there is no memory increase.