A customer site is experiencing poor performance. The UI response time is high and searches take a very long time to run. Some operations time out and there are errors in the scheduler logs…

Question

Options

• AChange the search heads to do local indexing of summary searches.
• BAdd heavy forwarders between the universal forwarders and indexers so inputs can be parsed
• CIncrease memory and CPUs on the search head(s) and add additional indexers.
• DIf indexed realtime search is enabled, disable it for the notable index.

• A
  6% (1)
• B
  22% (4)
• C
  56% (10)
• D
  17% (3)

Explanation

Upgrading search head resources (CPU/RAM) directly addresses the root cause: the scheduler errors about too many concurrent searches indicate the search head is resource-exhausted, and slow UI response with timeouts confirms it cannot handle the current load - more hardware gives it the capacity to run those 6 correlation searches without contention. Adding indexers helps by distributing search execution across more nodes, reducing the burden on any single machine.

Why the distractors are wrong:

• A is backwards - putting local indexing on a search head adds resource contention rather than relieving it; search heads and indexers should have separate roles.
• B addresses data ingestion pipeline parsing, which has nothing to do with search performance or UI latency - the bottleneck is clearly on the search/compute side, not data forwarding.
• D is a valid minor optimization in some cases, but the notable index in Splunk ES typically doesn't use indexed real-time search by default, making this largely irrelevant to the described symptoms and far too small a change to fix a systemic resource shortage.

Memory tip: When you see "too many concurrent searches + slow UI + timeouts," map that directly to search head resource exhaustion - the fix is always more compute (CPU/RAM) or more nodes to share the load, not pipeline or ingestion changes.

No community discussion yet for this question.