sm-shaw
commented
3 months ago Many thanks for the issue, I think I know what is happening here. Firstly, nothing has changed with autopilot at v4.10, and it has been recently tested a lot for v4.11 to add the performance profiles feature https://github.com/TPC-Council/HammerDB/pull/707. To troubleshoot, try running a single test without autopilot first to see if the problem persists so we can rule out autopilot.
If it does, what I think the issue is here is that from the screenshot it looks like use all warehouses is set, and we are printing out 1000s of lines of output due to a high warehouse count. With HammerDB jobs, ALL the output is stored in a SQLite database so every line it is printing is doing a SQLite insert when jobs are enabled - if a number of users are all doing this at the same time and the local disk where hammerdb is installed is not particularly fast then this can become a bottleneck with the issue you see, once every line is inserted and SQLite has caught up then it unfreezes and all works again.
To test this, try disabling jobs as we do for test workloads here https://www.hammerdb.com/docs/ch02s03.html
If it runs without problem, but you do want jobs enabled, as a workaround try commenting out the following line in the driver script in the GUI before you run it:
#puts "VU $myposition : Assigning WID=$wh based on VU count $loadUserCount, Warehouses = $w_id_input ([expr $addMore + 1] out of [ expr int($whRequiredCount)])"
lappend myWarehouses $wh
set addMore [expr $addMore + 1]If this works, then it looks like we need to consolidate the output of useallwarehouses as this works fine for a smaller number of warehouses, but it looks like a larger number puts too much pressure on the jobs storage.
A proposed solution is we already add $wh to a list for each line and therefore not print it for each line, and then we print all the warehouses added for a particular VU in one line when they are all allocated. This way we get all the same information but only in 1 (longer) line.
So for example, a prposed fixed is as follows:
} else {
# puts "VU $myposition : Assigning WID=$wh based on VU count $loadUserCount, Warehouses = $w_id_input ([expr $addMore + 1] out of [ expr int($whRequiredCount)])"
lappend myWarehouses $wh
set addMore [expr $addMore + 1]
}
}
set myWhCount [llength $myWarehouses]
puts "Assigned $myWhCount WIDs = $myWarehouses based on VU count $loadUserCount, Warehouses = [ expr int($whRequiredCount) ] out of $w_id_input"
}Then we get something like this, so the same information but only 1 SQLite insert per VU and should unfreeze the display.
Alex-Zarenin
Guidance Bug reports are for when HammerDB is not behaving as expected.
Describe the bug In the past releases of HammerDB, when using Autopilot for running test against SQL Server (could be with other platforms as well, but I did not test) the "Autopilot" tab was updated synchronously with creation of VUs. After all VUs were created, the screen was updated with every passing minute of ramp-up time.
With release 4.10, I noticed that the updates of the "Autopilot" tab freezes after creation of a few VUs and the all UI becomes unresponsive up until the end of the ramp-up time, at which point it unfreezes showing the history of ramp-up and becomes responsive again:
Autopilot Sequence 128 91 91 91 128 128 128 181 181 181 256 256 256 362 362 362 started at 00:08:35_07/02/2024 128 Active Virtual User Test started at 00:08:35_07/02/2024 with Monitor VU Beginning rampup time of 10 minutes Rampup 1 minutes complete ... Rampup 2 minutes complete ... Rampup 3 minutes complete ... Rampup 4 minutes complete ... Rampup 5 minutes complete ... Rampup 6 minutes complete ... Rampup 7 minutes complete ... Rampup 8 minutes complete ... Rampup 9 minutes complete ... Rampup 10 minutes complete ... Rampup complete, Taking start Transaction Count. Timing test period of 5 in minutes 1 ...,
To Reproduce Steps to reproduce the behavior:
Expected behavior I expect the screen to be updated with creation of every VU and then get updated as every minute of ramp-up time passes.
Screenshots If applicable, add screenshots to help explain your problem.
HammerDB Version (please complete the following information):
HammerDB Interface (please complete the following information):
Operating System (please complete the following information):
Database Server (please complete the following information):
Database Client (please complete the following information):
Additional context Add any other context about the problem here.