Monitoring Splunk

Set reduce_freq for a saved search?

Super Champion

Is there a way to explicitly set the reduce_freq for a given saved search? I don't see a dispatch.* option for this listed in the docs. Looks like you can globally set this in limits.conf, and it seems like you can pass in reduce_freq when you create a job by default, so it seems like you should be able to do this somehow.

I'm doing a lookup with the built-in dnslookup external python lookup script and it preforms quite poorly. I suspect that the search is re-calling the lookup command every 10 seconds (the default reduce_freq interval`), which is causing a slow search to be slowed down even more by a reverse DNS lookup. This is a summary indexing saved search so refreshing the results not a high priority.

Super Champion

I did some more digging around the config files and it appears that I've mostly figured out how to do this. I found in the $SPLUNK_HOME/etc/system/default/savedsearches.conf a global entry dispatch.reduce_freq = 10, which looks exactly like what I'm looking for.

The comment in limits.conf for the reduce_freq setting states:

the frequency with which try to reduce intermediate data when there is an non-streaming and non-stateful streaming command. (0 = never)

In my case, I would like to disable all intermediate calculations, so I simply used the following setting in savedsearches.conf:

dispatch.reduce_freq = 0

However, this doesn't seem to work. The reduce_freq stayed with the default value of 10,

On a second test, I find out that using a non-0 value does work. The specific search I'm looking at is nearly always done in 120 seconds or less, so I set the value to 180 to effectively disable this functionality. My entry now looks like this:

dispatch.reduce_freq = 180

This does the trick. I can now see via the OS process list that my saved searches are being run with the new value. ( ps aux | grep "splunkd search". The commands now show --reduce_freq=180 instead of --reduce_freq=10).


It looks like splunk is seeing dispatch.reduce_freq=0 the same as dispatch.reduce_freq=; both of which simply use the established default value. I'm not sure if this is a bug or a feature.