Resource usage of NSH Script Jobs
This topic outlines the resource usage for NSH Script Jobs. It includes the following sections:
NSH Script Job categories
Scripts executed by Network Shell (NSH) Script Jobs are categorized by the following options in the job's Add Script dialog:
- Execute the script separately against each host (Type 1)
- Execute the script once, passing the host list as a parameter to the script (Type 2)
- Copy and execute the script against each host separately (Type 3)
- Execute the script using the PERL interpreter, passing the host list as a parameter (Type 4)
From a performance perspective, Type 3 NSH Script Jobs differ from the other types in that they execute the script on the target instead of the Application Server. However, even for scripts executed on the Application Server,
nexec commands are executed on the target.
In BMC Server Automation version 8.0 and later, you have the option of selecting asynchronous execution for Type 3 NSH Script Jobs. Choosing this option causes the job to be executed by using asynchronous BlExec tasks. For information about asynchronous BlExec tasks, see Job execution framework.
For Type 2 and Type 4 NSH Script Jobs, processing of the host list parameter is under control of the script itself and typically results in the target hosts being processed sequentially. This can have undesirable performance implications for the NSH Script Job as a whole.
Factors that impact performance
The typical execution time for one target varies by:
The commands used inside the script as well as the typical performance of the target. For example, a “find” script looking across an entire file system will take much longer to execute than the “uname” command.
The managed server (target) count in scope for the task.
The available system resources on the Application Server(s) and the targets.
When time is constrained (for example, changes within maintenance windows) it is important to consider these factors:
Run tasks using Type 1 or Type 3 tasks in parallel.
Break tasks into parts or server lists into groups.
Manage other workloads for performance in critical maintenance windows.
NSH Script Jobs and the process spawner
NSH Script Jobs invoke the actual NSH scripts in a separate process. That separate process can be created and managed either by the Application Server or by a separately-running application known as the process spawner. Use of the process spawner can significantly reduce the overhead required for creating and tearing down the process used to execute the NSH script.
BMC has the following recommendations for using the process spawner:
- Version 8.0; version 7.6 and earlier — Use of the process spawner can result in deadlocks or hangs under high workloads. BMC does not recommend using the process spawner in these versions.
- Version 8.1 and later — Issues with deadlocks and hangs are resolved in version 8.1. Use of the process spawner offers significant performance benefits for NSH Script jobs. BMC recommends its use.
The following table shows a summary of resource usage by the process spawner.
Application Server CPU