I have a situation where my Splunk feed is coming in all via syslog, sourcetyped as syslog, yet containing many different kinds of data. I've set up index-time TRANSFORMS in my props.conf to split out these various events to have new sourcetypes, and then sending those sourcetypes to an appropriate index.
Then I look at my indexing metrics in Splunk on Splunk. I see that the indexer queue is taking approx. 20% CPU time, but the regexreplacementqueue is at nearly 25%! (Note that this is a 24-CPU system--is the percentage 25% of one CPU, or 25% of the total available processing power?)
Does this (relatively) high use of CPU time in the regexreplacement queue suggest that my regexes are inefficient? Are there suggestions to keeping this processing queue a little less busy?
Is the percentage 25% of one CPU, or 25% of the total available processing power?
That percentage represent the approximate usage of one CPU core.
Does this (relatively) high use of CPU time in the regexreplacement queue suggest that my regexes are inefficient?
Possibly, that does seem to be on the high side for the regexreplacement processor. That being said, what really matters is:
Are there suggestions to keeping this processing queue a little less busy?
Yes, but they are not always trivial to implement:
Is the percentage 25% of one CPU, or 25% of the total available processing power?
That percentage represent the approximate usage of one CPU core.
Does this (relatively) high use of CPU time in the regexreplacement queue suggest that my regexes are inefficient?
Possibly, that does seem to be on the high side for the regexreplacement processor. That being said, what really matters is:
Are there suggestions to keeping this processing queue a little less busy?
Yes, but they are not always trivial to implement:
Thanks for the feedback.
It doesn't appear that the regexreplacement pipeline is becoming an issue. Typing queue is not full, and not blocking earlier queues.
In this instance, the regexreplacement pipeline is in fact taking more time than the indexer pipeline, but I'm going to write that off to "good IO" and maybe poor regexes. I'll see if they can be improved.