Salt is able to run commands in parallel on a large number of clients. This can potentially create large amounts of load on your infrastructure. You can use these rate-limiting parameters to control the load in your environment.
These parameters are all configured in the
/etc/rhn/rhn.conf configuration file.
Salt commands that are executed from the command line are not subject to these parameters.
There are two parameters that control how actions are sent to clients, one for the batch size, and one for the delay.
When the Salt master sends a batch of actions to the target clients, it will send it to the number of clients determined in the batch size parameter. After the specified delay period, commands will be sent to the next batch of clients. The number of clients in each subsequent batch is equal to the number of clients that have completed in the previous batch.
Choosing a lower batch size will reduce system load and parallelism, but might reduce overall performance for processing actions.
The batch size parameter sets the maximum number of clients that can execute a single action at the same time.
Defaults to 100.
Increasing the delay increases the chance that multiple clients will have completed before the next action is issued, resulting in fewer overall commands, and reducing load.
The batch delay parameter sets the amount of time, in seconds, to wait after a command is processed before beginning to process the command on the next client.
Defaults to 1.0 seconds.
There are two parameters that control how presence pings from the Salt master are handled, one for the ping timeout, and one for the ping gather job.
Salt batch calls begin with the Salt master performing a presence ping on the target clients. A ping gather job runs on the Salt master to handle the incoming pings from the clients. Batched commands will begin only after all clients have either responded to the ping, or timed out.
The presence ping is an ordinary Salt command, but is not subject to the same timeout parameters as all other Salt commands (
gather_job_timeout), rather, it has its own parameters (
You can configure the global timeout values in the
/etc/salt/master.d/custom.conf configuration file.
However, to allow for quicker detection of unresponsive clients, the timeout values for presence pings are by default significantly shorter than those used elsewhere.
You can configure the presence ping parameters in
/etc/rhn/rhn.conf, however the default values should be sufficient in most cases.
A lower total presence ping timeout value will increase the chance of false negatives. In some cases, a client might be marked as non-responding, when it is responding but did not respond quickly enough. Additionally, setting this total presence ping timeout value too low could result in a client hanging at the boot screen. A higher total presence ping timeout will increase the accuracy of the test, as even slow clients will respond to the presence ping before timing out. Additionally, a higher presence ping timeout could limit throughput if you are targeting a large number of clients, when some of them are slow.
If a client does not reply to a ping within the allocated time, it will be marked as
not available, and will be excluded from the command.
The Web UI will show a
minion is down message in this case.
For more information on client timeouts, see scale-minions.adoc.
The presence ping timeout parameter changes the timeout setting for the presence ping, in seconds.
Defaults to 4 seconds.
The presence ping gather job parameter changes the timeout setting for gathering the presence ping, in seconds.
Defaults to 1 second.
In older versions, Uyuni used a tool called Salt mine to check client availability.
The Salt mine would cause clients to contact the server every hour, which created significant load.
With the introduction of a more efficient mechanism in Uyuni 3.2, the Salt mine is no longer required.
Instead, the Uyuni server uses Taskomatic to ping only the clients that appear to have been offline for twelve hours or more, with all clients being contacted at least once in every twenty four hour period by default.
You can adjust this by changing the
web.system_checkin_threshold parameter in
The value is expressed in days, and the default value is
Newly registered Salt clients will have the Salt mine disabled by default. If the Salt mine is running on your system, you can reduce load by disabling it. This is especially effective if you have a large number of clients.
Disable the Salt mine by running this command on the server:
salt '*' state.sls util.mgr_mine_config_clean_up
This will restart the clients and generate some Salt events to be processed by the server. If you have a large number of clients, handling these events could create excessive load. To avoid this, you can execute the command in batch mode with this command:
salt --batch-size 50 '*' state.sls util.mgr_mine_config_clean_up
You will need to wait for this command to finish executing. Do not end the process with Ctrl+C.