Skip to Content
Information
Important This documentation space contains information about PATROL Agents when deployed in a TrueSight Operations Management environment. If you are a BMC Helix Operations Management user, see PATROL Agent 22.4 for BMC Helix Operations Management.

Tuning the Scheduler

The RUNQ scheduler is a very important component in the agent. The behavior of the scheduler can be modified by the PATROL administrator and should not be modified by you as a developer. Although you should not modify these values from within PSL, it's important to know how the scheduler works, because the scheduler is responsible for executing your PSL scripts. This page provides information about following topics:

RUNQ Scheduler Attributes

The behavior of the scheduler is defined by attributes, which are stored inside the pconfig() database, as shown in the following figure 

RUNQ Scheduler Attributes 

RUNQ Scheduler Attributes.png

The purpose of these attributes is explained in the following sections. However, the constraints and defaults for these values include the following:

  • Schedule from end and from previous are mutually exclusive and at least one should be specified.
  • If both of them are specified, from previous is used, if none of them are specified, from end is used.
  • Force delta and optimal are optional and mutually exclusive. If both are specified, force delta will be used.

RUNQ Schedule Optimal

The algorithm to calculate the optimal schedule is quite complex, so instead of going too deep into details, this overview will help you understand it's operation. 

Whenever a new process wants to be scheduled, it will have a proposed execution time. This proposed execution time will be incremented with steps of runqDeltaIncrement until runqMaxDelta is reached. Any of these times will be seen as possible execution times. 

For each of those possible execution times, the agent will calculate the "time between executions" and the "standard deviation" for all of the already scheduled processes. This will return two values per possible execution time. The agent will then pick the execution time with the greatest time between executions as the new best-scheduled time for this parameter. 

The standard deviation is used whenever we have 2 schedule times with the same time between executions. The new execution time with then be the one with the smallest standard deviation. A small standard deviation is an indication of even (optimal) spreading. In case we would have chosen the execution time with the greatest standard deviation, then this would not indicate optimal spreading but be an indication of a lot of executions happening close to that time and one or a couple of executions would happen in a relatively long time from the new execution time. 

The following is the Algorithm to calculate optimal RUNQ schedule:

  1. Input proposed schedule time (t)
  2. Find optimal scheduling by calculating the following
    • Average time between executions
    • Standard deviation 

      for all possible t's and any other scheduled process, where t is incremented by runqDeltaIncrement until (t + runqMaxDelta) is reached
  3. Take greatest average between executions
  4. If two averages are the same, take the one with the smallest standard deviation (for a better spread)

Examples for Optimal Schedule

The scheduler will take the intervals of the parameters into account. In the following examples, 4 parameters are used, each having a different interval. 

The delta increment is 2 seconds and the Max Delta is 8 seconds (this is just an example, max Delta should normally be more than 10 seconds). If the process we want to schedule has an interval of 4 seconds, it would be best to schedule it at t=2 (or t=6)

Warning

Note

It is unlikely that a parameter will be executed on schedule. Also, the agent will try to prevent multiple parameters from executing at the same time. Developers cannot change this behavior and therefore must not expect that two parameters with the same schedule will run together.

Schedule Optimal: Example 1 

1.PNG

Slide 3.10: Schedule Optimal: Example 2 

2.PNG

Slide 3.11: Schedule Optimal: Example 3 

3.PNG

Slide 3.12: Schedule Optimal: Example 4 

4.PNG

RUNQ Schedule Force Delta

To force the delta, a process will only be scheduled if it will not run between runqDelta from another process. After a while, this will result in adding the processes at the end of the queue with the distance of runqDelta. 

This process is very simple to run. It searches until the interval between previous process and next process is at least runqDelta.

Initial RUNQ Scheduling

If a parameter were never scheduled before, the current time would be used as the proposed schedule time. To prevent all parameters to run at the same time, they will all be "scheduled optimal" (unless force delta was already specified). With this option in place, Schedule from End/Previous is ignored.

Normal RUNQ Scheduling

The "fine tuning" of the scheduler will happen after we get a new proposed execution time. 

This proposed schedule time depends on the setting of the policy. If you schedule from end, you will add interval to the current time after the parameter finishes to execute. (Interval will be forced) 

If you schedule from previous, you will take the previous exectime and add interval to it. 

After that the scheduling can be optimized, depending on the setting of the policy. This is an optional step.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

PATROL Agent 22.4