Configure batch mode search
A search running in batch mode searches one bucket at a time in batches instead of searching through events over time. Transforming searches that qualify for batch mode processing can complete faster than they would otherwise.
Batch mode search also improves the reliability for long-running distributed searches, which can fail when an indexer goes down while the search is running. In this case, Splunk Enterprise attempts to complete the search by reconnecting to the missing peer or redistributing the search across the rest of the peers.
Batch mode search functionality is enabled by default. See "Configure batch mode search" in this topic for information about configuring or disabling batch mode search.
Requirements for batch mode search
Transforming searches that meet the following conditions can run in batch mode.
- The searches need to use generating commands like
- The search can include transforming commands, like
chart, and so on. However the search cannot include commands like
- If the search is not distributed, it cannot use commands that require time-ordered events, like
Confirm whether or not a search is running in batch mode by using the Search Job Inspector. Batch mode search is indicated by the boolean parameter
isBatchModeSearch. See View the search job properties in the Search Manual.
Configure batch mode search
If your Splunk platform implementation runs on premise (as opposed to in the cloud), you can configure batch mode search throughout the implementation by changing settings in the
limits.conf configuration file, under the
When you have several batch mode search threads running concurrently, they can become a memory usage burden. You can deal with this by disabling batch mode search for your entire implementation, or by limiting the number of events that a batch mode search thread can read at once from an index bucket.
[search] allow_batch_mode = <bool> batch_search_max_index_values = <int>
true, meaning that batch mode search is enabled for qualifying transforming searches. Disable batch mode search by setting
allow_batch_mode = false.
allow_batch_mode = true, use the
batch_search_max_index_valuesto limit the number of events that the Splunk platform implementation read from the index file (bucket). These entries are small, approximately 72 bytes; however, batch mode is more efficient when it can read more entries at once. Defaults to 10000000 (or 10M).
For example, if your batch mode searches are causing you to run low in system memory, you can lower
batch_search_max_index_values to 1000000 (1M) to decrease their memory usage. Setting this parameter to a smaller number can lead to slower search performance. You want to find a balance between efficient batch mode searching and system memory conservation.
Set search peer retry period
limits.conf settings control the periodicity of retries to search peers in the event of failures, such as connection errors. The interval exists between failure and first retry, as well as successive retries in the event of further failures.
batch_retry_min_interval = <int> batch_retry_max_interval = <int> batch_retry_scaling = <double> batch_wait_after_end = <int>
- Use the
batch_retry_max_intervalparameters to specify the minimum or maximum interval (in seconds) to wait before Splunk Enterprise attempts to retry the search on a failed peer. The minimum interval defaults to 5 seconds. The maximum interval defaults to 300 seconds.
- After a retry attempt fails increase the time to wait before another retry by a scaling factor,
batch_retry_scaling, which takes a value greater than 1.0. Defaults to 1.5.
- Batch mode considers the search complete when all peers have indicated without failure that they have delivered the full answer. If the search finishes, but one or more of the peers has failed, batch mode retries connection with the failed peer(s) for the number of seconds specified by
batch_wait_after_end. If batch mode cannot reconnect within this period of time, it declares the search results to be incomplete. Defaults to 900 seconds.
Restart a fractured search
Restarting of the search peer is handled differently depending on whether the peer is clustered or not.
- In the non-clustered case, if a peer is lost, Splunk Enterprise will attempt to reconnect to the peer. Once the connection is re-established, the search resumes until completion.
- In a clustered case, Splunk Enterprise waits for the cluster master to spawn a new generation.
Configure summary indexes
This documentation applies to the following versions of Splunk® Enterprise: 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15, 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.1.14, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15