Recommendations for Application Servers of type Job

Number of threads that can be used to execute job parts, for parallelism. BMC recommends 100 work item threads for 64-bit Application Servers.

Number of threads that can be used to execute lightweight job parts, for parallelism.

If Deploy Jobs represent a significant percentage of the workload, BMC recommends using the default value of 200 in most cases.

If the value is set to 0, then zero threads for lightweight work items uses ordinary work item threads for the execution of all work items, lightweight or not.

Enables or disables the asynchronous execution framework for jobs that allow it (for example, Deploy Jobs). This is always set to true.
BMC recommends leaving asynchronous execution enabled.

Maximum simultaneous sockets opened by the BlExec service

BMC recommends using the default value of 500 in most cases. A higher value allows more simultaneous connections; a lower value reduces the demand for file descriptors.

Number of worker threads used by the BlExec service

BMC recommends using the default value of 20.

Number of approval threads

This parameter governs a small pool of threads used to communicate with TrueSight Orchestration.

Maximum number of jobs that the Application Server can execute simultaneously, regardless of the availability of resources to execute the jobs. Note that this limit applies to one Application Server only, and not to the whole deployed environment.

The default is 20. If you run many single target jobs (such at patch-generated Deploy Jobs), increasing this value can remove a bottleneck condition where MaxJobs is hit but there are available WorkItem Threads.

Note: If you are running batch jobs, the actual number of jobs running might exceed the MaxJobs setting. Number of jobs running is one of the statistics included in Application Server information in the Infrastructure Management window or in the detailed report that you can export from that window, as well as in the Application Server status report when you generate data for Support. The reason for this phenomenon is that only the batch job itself is counted towards the MaxJobs limit, while all jobs — the batch job and all its member jobs — are included in the count of number of jobs running.

Maximum number of threads that can be used to execute a job, for parallelism

This parameter specifies the maximum size for the job execution pool. BMC recommends a value of 5. The job execution pool is distinct from the work item thread pool. Although most of the work involved in executing a job is delegated to work items, some of the work (such as creating the work items) is the responsibility of the job and is carried out by the job execution pool.

Number of maximum client connections to the Application Server

BMC recommends estimating peak client connection demand, as described in Estimating client connections in Recommendations-for-Application-Servers-of-type-Configuration, and setting MaxClientContexts to this value. Note that in the case of Application Servers of type Job, client connections are established for BLCLI commands in NSH scripts that run on the Job server.

In the absence of sufficient information about peak client connection demand, BMC recommends using the default value of 200.

Number of client connection worker threads. While the Application Server is defined as a JOB server type, any NSH Script Jobs that use BLCLI commands that the server runs will need a client connection and they will connect to whatever is defined in the blasadmin Auth | AppServiceURL setting. By default this is blank (and should be left as such) and the server will connect to itself.

BMC recommends using the default value of 10, or approximately 5 percent of the value of MaxClientContexts.

Maximum heap size for this Application Server.

These connections are used for communication between Application Servers. In environments with many Application Server instances, this setting may need to be increased from the default of 20.

These settings specify a range of available ports used for communication between Application Servers. The default range provides for 50 ports (BasePort+50-BasePort+9899) which is sufficient for most environments.

Use the default value, which is 10.

Global default value for job parallelism made available to the user

This parameter has no direct effect on the operation of the Application Server. Rather, it is the default value that appears in the UI for a job's maximum parallelism option, when that option is selected.

The recommended value is 30. In a large environment, you might want to set a lower number to constrain how many WorkItemThreads a single job can consume by default.

Note: This setting is not applied to File Deploy Jobs and Network Shell Script Jobs.

Maximum connections in the pool for the job execution thread group. This connection pool is used by NSH script jobs to log output and all other job types.

BMC recommends a value that is twice the number of work item threads (MaxWorkItemThreads).

Controls the minimum number of database connections created on startup for the General Connection pool. Because connections are created on demand, this has no impact on performance.

Maximum connections in the pool for client connections. Use the following rules of thumb:

• For an Application Server configured to act exclusively as a Job server, this value should be 2 times the value of the MaxWorkerThreads setting.
• For an Application Server configured to act as both a Job server and an NSH proxy server, this value should be 2 times the sum of the values for MaxWorkerThreads + MaxNshProxyThreads.

Controls the minimum number of database connections created on startup for the Client Connection pool. Because connections are created on demand, this has no impact on performance. The default is 0.

Maximum idle time, in seconds, for database connections. The Application Server closes database connections that are idle longer than the specified timeout. If there is a network device between the Application Server and database with a lower idle timeout, then this setting should be adjusted. The default is 600 seconds (10 minutes).

Controls logging of long running database queries. Leave at 0 to disable this functionality.

Number of rows fetched simultaneously from the database. The default is 100 rows.

Number of seconds that connections are idle before being tested. The default is 600 seconds (10 minutes).

Maximum number of database connections created for the General Connection pool before starting the Application Server. BMC recommends to keep the same value as ConnectionPoolMaxSize.

Application service URLs distributed in the session credentials issued by the Authentication Service

For a Job instance, the setting should remain blank. This will ensure that any NSH Script Jobs that contain BLCLI calls will direct requests to the instance that is running the Work Item Thread associated with the Job and nowhere else. 

If the instance is an ALL instance, then an alias for the load balancer should be added to the local hosts file on the Application Server, so that the load balancer URL resolves to the local system. This prevents network communication issues that might result from a node behind a load balancer trying to talk to itself through the same VIP that it sits behind. The load balancer vendor might have specific configuration settings to handle this situation, as well.

NSH Proxy service URLs distributed in the session credentials issued by the Authentication Service.

For a Job instance, the setting should remain blank if the instance is a combined JOB+NSH_PROXY. This will ensure that any Jobs that use an NSH Proxy will direct requests to the instance that is running the Work Item Thread associated with the Job and nowhere else. 

If the instance is an ALL instance, then an alias for the load balancer should be added to the local hosts file on the Application Server, so that the load balancer URL resolves to the local system. This prevents network communication issues might result from a node behind a load balancer trying to talk to itself through the same VIP that it sits behind. The load balancer vendor might have specific configuration settings to handle this situation, as well.

If the NSH_PROXY instance is a standalone instance, or you want to direct the NSH Proxy communication to another instance that runs the proxy, the network path must be considered. For example, would the communication from the Job instance to the NSH Proxy instance result in the same situation as the above where a node behind a load balancer tries to communicate with itself through the VIP? If so, the hosts alias should be used here, as well.