Browse Prior Art Database

Method for restraining automation resources from starting/stopping all at the same time in a custom controlled means to increase overall system performance Disclosure Number: IPCOM000237991D
Publication Date: 2014-Jul-24
Document File: 3 page(s) / 35K

Publishing Venue

The Prior Art Database


This article describes a method how to increase overall system performance during startup or shutdown phases, when many workloads are started or stopped, respectively in parallel. The core idea is to artificially restrain workloads eligible for start or stop under the control of the operations team.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

Page 01 of 3

Method for restraining automation resources from starting /

/stopping all at the same

stopping all at the same

time in a custom controlled means to increase overall system performance

Automation solutions typically are capable of starting new workloads when a set or predecessor conditions become satisfied (for example, specific pre-requisite workloads are up, some offline actions have occurred etc.). At this point all of the workloads that are ready to be started in the next 'wave' are released.

Depending on the number and nature of the workloads being started 'en-mass' and the systems current utilization this may or may not cause operational issues such as excessively long start times or degradation of already running workloads. That might be acceptable during initial system start but may not be acceptable if there is the need to recover in place or failover to another system in the middle of the day.

Not all workloads are equal, so simply applying a broad throttle to the release of the

workloads is not sufficient. Such a broad control may still release many very resource hungry workloads while holding back many other workloads that have little, if any impact on the overall situation. At the end, such a solution may be even worse as some other workloads will be forced to wait for many held back workloads to start before they are being released.

To some degree, there are workload management solutions available, that can control

what workload will get what amount of resources at any given time. Work is categorized in buckets and either an absolute or relative capacity is assigned to the buckets. In case of resource shortages, such a workload management system drives compute resource assignments towards the rules that have been set before.

In the situation of parallel start and stop of workloads, also referred to as processes or address spaces, however, even a workload management system cannot do anymore an accurate compute resource management, if these processes all fall into the same bucket. Once a process has been started, the operating system will give those processes the compute resources they request with the help of the built-in workload management system or simply using its own scheduling and memory management algorithms part of the operating system. Operating systems and known workload management systems lack granular entitlement capabilities that allow the administrator to define what processes can be started or stopped when and how many of those processes may be started or stopped at most at the same time. Such questions are typically dependent very much to the actual operating environment and therefore left to the operating team.

So, what is needed is a solution, where these questions can be answered outside of the operating system itself but still inside the operating environment. The approach therefore is to define a set of pacing gates with their own pacing rates and then to associate individual workloads with a spec...