The following table shows best practice recommendations for tuning the Control-M/Server application.
Make sure to test your current performance before and after the changes to ensure that these recommendations fit your job types and jobs flow activity patterns. The configuration parameters should be added to the ctm_server/data/config.dat file unless Filename is provided below. Depending on the Control-M version, the parameters may not exist or are stored in a different configuration file. Note that any CE thread parameter change require a restart of the Control-M/Server processes with the commands: shut_ctm and start_ctm
|
Parameters
|
small
|
medium
|
large
|
|
Number of Daily Active Jobs
|
0 – 15,000
|
15,001 – 75,000
|
75,001 – 150,000
|
|
Number of Daily Job Executions
|
0 – 15,000
|
15,001 – 75,000
|
75,001 – 150,000
|
|
DOWNLOAD_THREADS
|
3
|
6
|
8
|
|
DB_UPDATE_THREADS
|
2
|
4
|
8
|
|
SEL_IO_THREADS
|
3
|
6
|
12
|
|
POST_PROCESS_THREAD_POOL_SIZE
|
4
|
8
|
12
|
|
AGENT_UTILS_THREADS
|
4
|
30
|
60
|
|
AGENT_APP_STATUS_UPDATES_THREADS
|
4
|
8
|
12
|
|
TRACKER_WORKERS_NUM
|
5
|
30
|
80
|
|
NS_THREADS
|
20
|
100
|
250
|
|
VIEW_SYSOUT_THREADS
|
20
|
40
|
60
|
|
CTMS_JVM_MAX_HEAP
|
2048
|
4096
|
8192
|
|
# of CS processes run ctm_menu on the Control-M/Server machine and navigating to option: Parameter Customization > Advanced Communication and Operational Parameters > Max/Min server processes (CS)
|
3
|
9
|
20
|
|
CTM_CONFIG_AGENT_NUM_OF_EXECUTERS
|
4
|
6
|
10
|
|
9.0.x - 9.0.20.200:
ORDERING_THREAD_POOL_SIZE
9.0.21.000 - 9.0.21.100:
File:~/ctm_server/services/config/ctms-order-service-application.yml
maxThreadPoolSizeForUserDailyProcessing
9.0.21.200 and higher:
ORDERING_THREADS_SIZE
|
4
|
8
|
12
|
|
9.0.21.200 and higher:
ORDERING_MAX_CONCURRENT_JOBS
|
20000
|
30000 |
40000 |
|
9.0.21.000 - 9.0.21.100:
File:~/ctm_server/services/config/ctms-order-service-application.yml
maxThreadPoolSizeForPriorityOrderProcessing
9.0.21.200 and higher:
ORDERING_PRIORITY_THREADS_SIZE
|
4
|
8 |
16 |
|
9.0.21.000 - 9.0.21.100:
File: ~/ctm_server/services/context/ctms-job-info-service.yml:
-Xmx256m
9.0.21.200 and higher:
File:.~/ctm_server/services/config/custom/BootPropertiesUserOverride.yml
ctms-job-info-service: MaxMemoryInMB:
|
128
|
256
|
1024
|
|
9.0.21.000 - 9.0.21.100:
File: ~/ctm_server/services/context/ctms-order-service.yml:
-Xmx1024m
9.0.21.200 and higher:
File:.~/ctm_server/services/config/custom/BootPropertiesUserOverride.yml
ctms-order-service: MaxMemoryInMB:
|
1024
|
2048
|
4096
|
|
JAVA_SCHEDULER_THREAD_POOL_SIZE
|
10
|
20
|
40
|
|
9.0.22 : The Service "scheduling-service" has been deprecated
9.0.20.000 - 9.0.21.100:
File: ~/ctm_server/services/context/scheduling-service.yml:
-Xmx1400m
9.0.21.200 - 9.0.21.300:
File:./ctm_server/services/config/custom/BootPropertiesUserOverride.yml
scheduling-service: MaxMemoryInMB:
|
1400
|
2200
|
3000
|
|
9.0.21.000 - 9.0.21.100:
File: ~/ctm_server/services/context/ctms-api-gateway-service.yml
-Xmx128m
9.0.21.200 and higher:
File:./ctm_server/services/config/custom/BootPropertiesUserOverride.yml
ctms-api-gateway-service:
MaxMemoryInMB:
|
1024
|
2048
|
4096
|
|
9.0.20.000 - 9.0.21.100:
File: ctm_server/services/config/scheduling-service-application.yml
Add maxConcurrentJobs: parameter at the bottom of the "internal:" section, set parameter to
9.0.21.200 and higher:
SCHEDULING_MAX_CONCURRENT_JOBS
|
6000
|
9000 |
12000 |
The highlighted item are impact more by number of Agents and type of job types rather than to volume of jobs.
CPU SPEC this value is calculated for configuration with BMC PG on the same host. To identify the type of hardware that will meet this requirement see spec.org website. To get an equivalent SPEC int_rate 2017 from SPEC int_rate 2006, divide 2006 value by 10 and add 5% additional. e.g 100 SPEC int_rate 2006 is equivalent to 10.5 SPEC int_rate 2017
Memory this value is calculated for configuration with BMC PG on the same host.
AGENT_APP_STATUS_UPDATES_THREADS This parameter dictates how many threads are used to send EM information that populate the MFT dashboard on EM. If you have reasonable number of MFT jobs then this parameter should be doubled.
AGENT_UTILS_THREADS Agent utility threads are used to process agent utilities invoked on the Agent machine. There are several utilities found in the Agent "exe" folder that are processed by Control-M/server and impact the definition of active jobs and their flows. Each thread handles a single invocation of the utility. If there are more concurrent utilities running than the number of threads then the utilities are queued. Increasing this value allows more Agent utilities to run concurrently.
NS_THREADS NS thread handle individual requests sent to the Agent, such as get job output, submit job, track the status of a job. In transient communication mode the if there are more request to the Agent than the number of NS threads then the requests are queued. If the Agent is very busy even if you dont have that many jobs in AJF you may want to increase the number of NS threads to improve the throughput. This value of parameter should not exceed 350 unless instructed by support.
CTMS_JVM_MAX_HEAP When number of threads are increased the Java process needs more resources to handle the additional activity. You should consider moving up the memory and CPU required when the thread counts are increased from the default. The value of this parameter will be printed in a SU log in the Control-M/Server proclog directory when the Control-M/Server comes up
# of CS processes CS process are used to handle EM user requests. If there are many EM users or if Workload Archiving is the environment then the number of concurrent requests will be higher and the number of CS process will need to be increased quicker then what is recommended above. The current value can be found by running ctm_menu on the Control-M/Server machine and navigating to the following options: Parameter Customization > Advanced Communication and Operational Parameters > Max/Min server processes (CS)
Number of Daily Job Executions: The values provided are intended to help determine the appropriate sizing category for your environment. They do not represent a limit on the number of executions. Execution capacity is guided by machine throughput. Environments with high throughput can support a higher daily job execution volumes. We recommend validating your hardware configuration to ensure it can support the desired number of daily job executions.
Job Ordering:
ORDERING_THREAD_POOL_SIZE - Determines how many Table orders can be done in parallel for all order operation such as userdailies, system dailies, or simple table orders. (9.0.00 - 9.0.20)
maxThreadPoolSizeForUserDailyProcessing (9.0.21 +) - Determines the number of threads of the order service to process user/utilities/doforce order requests. Each folder is being processes by a different thread. Increasing number of thread also requires increase in Java runtime memory. Restart is required for changes to take effect.
maxThreadPoolSizeForPriorityOrderProcessing (9.0.21 +) - Determines the number of threads of the order requests at new day, system daily. Each folder is being processes by a different thread. Increasing number of thread also requires increase in Java runtime memory. Restart is required for changes to take effect.
The Server limits/’control’ of the memory usage of the order service. The Order service by default is limited to load up to 20000 jobs while working on determining if a job should be ordered. The Service will wait until one of the threads finishes to handle a folder, before submitting additional folders.
JAVA_SCHEDULER_THREAD_POOL_SIZE - Determines how many threads can work in parallel to evaluate if a job of the same priority can be submitted for execution.
maxConcurrentJobs/SCHEDULING_MAX_CONCURRENT_JOBS - This parameter is required when using ctmrpln utility and the number of jobs in the report is greater than 6000
Additional Information:
How to tell if when the thread counts are hitting the maximum configured values.
Control-M/Server provides utility ctmipc to send control message to any of its processes in order to print diagnostics and configuration information. Running command:
ctmipc -dest CE -msgid CTL -data "CtmThreadPool"
A table will be display for each thread pool with the configured thread information and the "peak" number of threads utilized since the last time this utility was executed.
The output from the ctmipc command will not show values for TRACKER_WORKERS_NUM or CTM_CONFIG_AGENT_NUM_OF_EXECUTER because those parameters do not affect the CE process, they affect the TR and CA processes, respectively.
All parameters other than # of CS are configured in ~/ctm_server/data/config.dat file
DISCLAIMER:
BMC Software is providing these recommendation to help users and potential users of BMC Control-M Workload Automation to determine the hardware resources and best practices configuration parameters needed for using this particular BMC product. BMC Software intends to provide meaningful and accurate information, but does not guarantee the information is relevant or appropriate to your computing environment. Be mindful of the fact that the results of the tests are based on specific job attributes that may not reflect your specific scenario.
BMC Software does not make any warranty, expressed or implied, with respect to the information in this document, nor guarantees the accuracy, completeness, usefulness, or adequacy of this information. BMC Software will not be liable for any damages, including special, indirect, or consequential damages, arising out of or in connection with the use of the information provided in this document.