An HSM administrator might find it helpful to know how busy the HSM is and at what percentage of its capacity it has been running.
The HSM Information Monitor is a use counter that provides an indication of momentary and cumulative resource usage on the HSM, in the form of a percentage. The HSM firmware tracks the overall time elapsed since the last reset (Up-Time), and the overall time during which the processor was not performing useful work (Idle-Time).
On request, the HSM calculates "Busy-time" over an interval, by subtracting Idle-time for that interval from Up-time for the interval. Then, the load on the processor is calculated as the Busy-time divided by the Up-time, and expressed as a percentage.
You can use the available commands for a single, one-off query, which actually takes an initial reading and then another, five seconds later (the default setting), in order to calculate and show the one-time difference.
You can specify a sampling interval (five seconds is the shortest) and a number of repetitions for an extended view of processor activity/resource usage. The resulting records, showing the time of each measurement, the percentage value at that time, and the difference from the previous measurement, can be output to a file that you import into other tools to analyze and graph the trends.
By watching trends and correlating with what your application is doing, you can:
>Determine the kinds of loads you are placing on the HSM.
>Seek efficiencies in how your applications are coded and configured.
>Plan for expansion or upgrades of your existing HSM infrastructure.
>Plan for upgrades of electrical capacity and HVAC capacity.
Notes about Monitor/Counter Behavior
When performing certain operations the HSM reaches its maximum performance capability before the counter reaches 100%. This occurs because the counter measures the load on the HSM’s CPU and the CPU is able to saturate the asymmetric engines and still have capacity to perform other actions.
Also, symmetric cryptographic operations cause the counter to quickly rise to 90% even though there is significant remaining capacity. This behavior occurs because, as the HSM receives more concurrent symmetric commands, its CPU is able to handle them more efficiently (by performing them in bulk) – thus achieving more throughput from the same number of CPU cycles.
See lunash:> hsm information.
