TPC-OSS Alignment: Add Detailed System, Hardware, and Software Fields to Results

[sm-shaw]

Is your feature request related to a problem? Please describe.
From discussion at TPC-OSS subcommittee meeting 16th December 2025. For facilitating uploading of HammerDB results to the TPC it is necessary to gather more system information on the SUT (system under test). currently HammerDB only gathers the CPU information and e.g. this is shown in the

GUI

CLI

$ ./hammerdbcli
HammerDB CLI v5.0
Copyright © HammerDB Ltd hosted by tpc.org 2019-2025
Type "help" for a list of commands
Initialized Jobs on-disk database /opt/845/HammerDB-5.0-Dev/TMP/hammer.DB using existing tables (5,005,312 bytes)
hammerdb>metstart
Starting Local Metrics Agent on ubuntu24
after#1
hammerdb>Connecting to Agent to Display CPU Metrics
Metric receive port open @ 21389 on ubuntu24
Connecting to HammerDB Agent @ localhost:10000
Testing Agent Connectivity...OK
Metrics Connected
Started CPU Metrics for Intel(R) Core(TM) i9-14900KS:(24 CPUs)
CPU all usr%-0.05 sys%-0.09 irq%-0.00 idle%-99.82
CPU all usr%-0.05 sys%-0.00 irq%-0.00 idle%-99.86

and in the WS

Describe the solution you'd like
The desired solution is to gather the following additional information and store it in HammerDB.

• Result sponsor’s logo or GitHub profile name (linked to GitHub profile) - Not possible from HammerDB
• System Vendor and Type
  - Processor - DONE
  - Cores - DONE
• Memory
• NIC
• Disk/Storage
• Cloud Instance
  - Performance (depends on Benchmark) DONE
  - Database DONE
• OS
• Other Software
• Extra field, content depends on benchmark (scale factor, warehouse)

Describe alternatives you've considered
It is noted that the data needs to come from the SUT and not the HammerDB client and therefore we will need to extend the current CPU data approach that is gathered by the agent to discover the other system details. This also enables the user not to gather this data by not running the metrics agent.

Currently the agent when run discovers the CPU configuration, when the HammerDB GUI or CLI metrics is run it connects to the agent and the agent calls DoDisplay in the HammerDB GUI/CLI.

Agent send $f DoDisplay $S(cpus) [ list $cpu_model] agent

DoDisplay then inserts the CPU data into the JOBSYSTEM SQLite table before running the CPU metrics. This data is then shown as above when the Webservice is run by being retrieved from the table.

INSERT INTO JOBSYSTEM(jobid,hostname,cpumodel,cpucount) VALUES('@@@',$agent_hostname,$cpu_model,$maxcpu)

Note that the metrics may be run before a job is started and may not be identified with a JOBID, therefore there is a system in place to maintain a placeholder named '@@@' for the metrics data gathered until a job is started to associate with it.

The proposed solution is to add a DoDiscovery proc to the metrics and metricscli functionality. The Agent will be extended to gather the additional data required and call DoDiscovery with a send command when the agent connects. This will then insert this data into an extended JOBSYSTEM table with the additional fields above. It will be planned to move all inserts into the JOBSYSTEM table including the CPU data into DoDiscovery and just have DoDisplay fetch the previously stored CPU data.

Once this data is fetched and stored in the JOBSYSTEM table it should then be straightforward to extract it with other data to submit a result. This data will also be shown under the System link in the web service results.

Additional context
It is noted at this stage that both Oracle and PostgreSQL metrics in the GUI have Active Session Metrics in addition to just CPU metrics with MySQL and MariaDB planned. CPU metrics is a subset of the ASH metrics, therefore this means if ASH is not configured for Oracle or PostgreSQL then the CPU data will not be gathered. e.g. for PostgreSQL you would have to have configured and use pg_sentinel before you start gathering the CPU data. This is not the case in the CLI. It will therefore be necessary to add a "No ASH" option to Oracle and PostgreSQL GUI metrics as part of this process to just display the current CPU metrics display and gather the data from the agent rather than the full database metrics.

A follow on Issue could be to enable a similar iostat based I/O display to the one currently used for CPU.