Advanced Deployments - Implementing Splunk: Big Data Reporting and Development for Operational Intelligence - page 340

The measurements mentioned next assume that you will spread
events across your indexers evenly, using the autoLB feature
of the Splunk forwarder. We will talk more about this under
Indexer load balancing .
The model system looks like this:
• 8 gigabytes of RAM
If more memory is available, the operating system will use whatever Splunk
does not use for the disk cache.
• Eight fast physical processors
On a busy indexer, two cores will probably be busy most of the time,
handling indexing tasks. It is worth noting the following:
° More processors won't hurt but will probably not make much of a
difference to an indexer as the disks holding indexes will probably
not keep up with the increased search load. More indexers, each
with its own disks, will have more impact.
° Virtualized slices of cores or oversubscribed virtual hosts do not
work well, as the processor is actually used heavily during search,
mostly decompressing raw data.
° Slow cores designed for highly threaded applications do not work
well. For instance, you should avoid older Sun SPARC processors or
slices of cores on AIX boxes.
• Disks performing 800 random IOPS (input/output operations per second)
This is the value considered fast by Splunk engineering. Query your favorite
search engine for splunk bonnie++ for discussions about how to measure
this value. The most important thing to remember when testing your disks
is that you must test enough data to defeat disk cache. Remember, if you are
using shared disks, that the indexers will share the available IOPS.
• No more than four concurrent searches
Please note that:
° Most queries are finished very quickly
° This count includes interactive queries and saved searches
° Summary indexes and saved searches can be used to reduce the
workload of common queries
° Summary queries are simply saved searches