License Overbooking in vovresourced

The Overbooking function (Controller) in vovresourced is called vtk_flexlm_overbook and has a number of tuning parameters:

-thresh real

This is the threshold at which overbooking becomes active. For example if the value is set to 0.8 it means that when the job count reaches 80% of the allowed total, overbooking starts increasing the number of submitted jobs. The default value for the parameter is 0.9.

-factor real

This is number is used to scale the Measured Error into the additional number of jobs to submit. Common values are 0.8. The default value for this parameter is 1.0.

-headroom int

When the license in-use counts is greater than the maximum number of licenses less the headroom, the overbooking quantity is throttled. Negative headroom values are often used. The default value of headroom is 0.

-queued int

When Allocator sees this number of licenses queued (for example, in vendor-queuing) then the overbooking quantity is throttled. Generally this should be a small number. The default value is 1.

-lowpass int

To smooth the effect of overbooking, the actual correction is low-pass filtered. This option controls the delay of the filter. The larger the number, the longer the delay and the smoother the correction. The default value is 8.

-enable BOOL

Simple way to enable/disable an overbooking rule.

-verbose BOOL

Increase verbosity.

-v

Same as -verbose 1.

Tuning Overbooking

The optimal values for the overbooking parameters are workload specific. While the default values work in many cases, it is worthwhile to review the overbooking operation. Use the -verbose 1 option to monitor the behavior of the overbooking routines in the resource daemon log file. The goal should be to increase the license utilization close to 100% but without pushing too many jobs into vendor queueing. Vendor queuing implies that a hardware slot is taken but the job is stalled waiting for that license; normally a few slots being idle for a few seconds is a reasonable tradeoff for high license utilization. However, administrators should be aware that having too many jobs in vendor queueing can cause the license daemons to stall, dramatically reducing overall throughput.

If your workload ends up pushing too many jobs into vendor queuing before backing off, even with a small value of -queued then consider reducing the factor from 1.0 to 0.9 or lower, and increasing the headroom from 0 to 2-5% of the maximum license quantity.

If your workload struggles to get any vendor queuing, it may be because the threshold is not reached or maintained - particularly when the new total (maximum number of jobs) has been increased. Reducing the threshold to 0.8 or 0.7 will enable overbooking to continue to be active. For a large number of short duration jobs, there can be many jobs "in-flight": jobs for which license matching by Accelerator has not yet occurred. In these cases, it may make sense to increase -factor N to about 1.2 and have a negative value of headroom equal to 2-5% of the total license count.

While overbooking exhibits the self compensation characteristics expected from a control loop, tuning the parameters is often worthwhile for optimal usage.

Example of Overbooking in vovresourced

# Fragment of resources.tcl 
# Example of overbooking of hspice.

vtk_flexlm_monitor_all   ; ## This must be called before vtk_flexlm_overbook.

#
# Overbook the feature hspice up to the point where there are 5 jobs in vendor-queue.
vtk_flexlm_overbook hspice -queued 5

## All valid options.
vtk_flexlm_overbook myspice -thresh 0.9 -factor 1.0 \
     -headroom 2 -queued 3 \
     -enable 1 \

% ncmgr reset