This article helps to understand the basics of the PivotalVRP trigger mechanism.
Understanding the basic architecture of the rules engine helps when defining rules.
The rule definition windows:
The PivotalVRP Rule triggers are divided under 4 tabs:
The basic, general, advanced and rules activation overrides tab provide a series of triggers that allow activation of various functions within PivotalVRP.
The 4 rules tabs (basic window).
The first 3 tabs (basic, general and advanced) are based on thresholds relating to the single process itself.
The rules activation tab is triggered by loads on the segment itself (CPU & IO) and has options relating to the mechanism based on importance on a scale from 1 to 25 and enables the option to be activated by other rules.
The rule activation overrides tab.
Understanding single process vs segment resource usage.
The 3 first tabs in the rule threshold window validate triggers against single process parameters such as runtime, user CPU usage, IO usage etc...
The rule activation override validates (CPU & IO) resource consumption at the segment level.
If a segment has 4 cores available to it, it can get an aggregated total of 400% CPU (4 cores at 100%) but at the segment level it is 100% of total resources.
Each single process (or slice) can take up to 100% of a SINGLE core, therefore if we have one slice running at 100%, at the segment level the CPU usage is only 25%.
So if in PivotalVRP we set the rule activation override trigger at 50% (see illustration below) the load at the segment level would need to be above 50% in order to trigger the rules.
Once the segment load reaches 50%, the trigger mechanism will look for additional trigger validation at the process (slice level).
If on the rule set in the illustration above the basic tab will include a trigger of 50% CPU (see below), when the segment load level reaches 50%, any process using 50% or more will activate the rule.
So if we have 2 processes running that contribute to the overall load level that triggers the rule at the segment level (rule activation override) and only one of them crosses the 50% consumption mark, the rule will only affect that process (see illustration below).
Resource management through PivotalVRP
PivotalVRP resource management can be performed 2 ways; Manual & Automatic (through the Rules Engine). PivotalVRP manages both CPU & IO at the single process level (which in turn also affect memory and network).
The Manual Resource control is done by right-clicking a query within the PivotalVRP dashboard.
You can select the parent (bold) and the control level will apply to all the processes (children) or choose just a single slice and control just the single process.
This is a one-time ad hoc control for the session or slice, once it ends its run the resource management will cease and it will not be repeated if it restarts at a later time (or in parallel).
The control applies to 1-99% of the potential resources the process could consume, ie.: if a process would utilize 50% CPU & 1,000 IOs at 50% control it would receive up to 25% CPU and 500 IOs.
Resource management by way of the VRP rules engine is dynamic, the resources are managed only when the triggers are activated, the control is as explained above.
The rules engine however has an additional option which can help dealing with resource starvation due to concurrency.
When multiple processes are running in parallel, PivotalVRP can allocate the resources of a single occurence to multiple runs of the same session, ie.: session “A” can consume 100% CPU & 10,000 IOs, if we click the “Distribute resources equally” button (Illustration D, bottom arrow) and limit resources to 50%, 1 run
of the session will get 50% CPU & 5,000 IOs, if we run 2 sessions in parallel each will get 25% CPU & 2,500 IOs (50% & 5,000 IOs divided by 2), if more of the same sessions are launched they will share the 50% CPU & 5,000 IOs.