Related Answers
Download topic as PDF
Summary of performance recommendations
The Daily Indexing Volume table summarizes the performance recommendations that were given in the performance checklist. The table shows the number of reference machines that you need to index and search data in Splunk Enterprise, depending on the number of concurrent users and the amounts of data that the instance indexes.
An indexer that meets the reference hardware requirements can ingest up to 300GB/day while supporting a search load. For a review of the current reference hardware specifications, see Reference hardware in this manual.
The table is only a guideline. Modify these figures based on your use case. If you need help defining and scaling a Splunk platform environment, contact your Splunk Sales representative or Professional Services.
| Daily Indexing Volume | |||||||
|---|---|---|---|---|---|---|---|
| < 2GB/day | 2 to 300 GB/day | 300 to 600 GB/day | 600GB to 1TB/day | 1 to 2TB/day | 2 to 3TB/day | ||
| Total Users: less than 4 | 1 combined instance | 1 combined instance | 1 Search Head, 2 Indexers |
1 Search Head, 3 Indexers |
1 Search Head, 7 Indexers |
1 Search Head, 10 Indexers | |
| Total Users: up to 8 | 1 combined instance | 1 Search Head, 1 Indexers |
1 Search Head, 2 Indexers |
1 Search Head, 3 Indexers |
1 Search Head, 8 Indexers |
1 Search Head, 12 Indexers | |
| Total Users: up to 16 | 1 Search Head, 1 Indexers |
1 Search Head, 1 Indexers |
1 Search Head, 3 Indexers |
2 Search Heads, 4 Indexers |
2 Search Heads, 10 Indexers |
2 Search Heads, 15 Indexers | |
| Total Users: up to 24 | 1 Search Head, 1 Indexers |
1 Search Head, 2 Indexers |
2 Search Heads, 3 Indexers |
2 Search Heads, 6 Indexers |
2 Search Heads, 12 Indexers |
3 Search Heads, 18 Indexers | |
| Total Users: up to 48 | 1 Search Head, 2 Indexers |
1 Search Head, 2 Indexers |
2 Search Heads, 4 Indexers |
2 Search Heads, 7 Indexers |
3 Search Heads, 14 Indexers |
3 Search Heads, 21 Indexers | |
|
PREVIOUS Determine when to scale your Splunk Enterprise deployment |
NEXT Forwarder-to-indexer ratios |
This documentation applies to the following versions of Splunk® Enterprise: 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 8.0.0
Comments
Suppose I have 1000 simultaneous users who will be accessing a particular dashboard having 10 panels and each panel is refreshed every 5 or 10 minutes, what would be the recommended number of Search Heads and Indexers would be required to handle the above 1000 users load ? Also, currently we are ingesting approx 110GB/day. Please advise ?
Hi Sealydi,
I think there might be some misunderstanding on the terms here.
One user can absolutely spawn any number of real-time searches, thus raising the number of concurrent *searches*, but that is still only one *user* that is spawning those searches. A user that is logged in uses a core for their session, plus any cores that their searches take up.
This page, like the reference hardware page, lists the baseline requirements, derived from the number of concurrent Splunk users. Results will vary, and the more search-intensive your usage is, the higher the *initial* requirements will be.
As soon as we get that updated information, it will be posted here. Thanks for your comments.
Hi Malmoore,
I'm surprised in your response to Htidore comment that this was considered 1 user rather than 50. Surely this scenario has 50 concurrent searches, with each search consuming a CPU? (as per https://docs.splunk.com/Documentation/Splunk/7.0.3/Capacity/Accommodatemanysimultaneoussearches).
We have a similar issue. We don't do real time panels due to the performance overhead but rely heavy on dashboards for our workflow. Users can change global inputs on these dashboards and resubmit. Some of these dashboards have 10+ panels. Even with quick search return times, when we have multiple users heavily using these dashboards we run into search queue issues and performance degradation.
This page appears to make the assumption that a user will only ever being doing a singular search which is not realistic. I would be very interested in these "improved, clearer performance figures for this page" you mention.
Hi Htidore,
The users count represent a concurrent user that runs one or more searches. As CPU cores on an indexer are only in use for search when a search is active, we only count users when they are actively searching. So, at this time, the closest answer to your question would indeed be one.
We are working on getting improved, clearer performance figures for this page. However, I can't promise when those figures would become available.
Hi Frankwayne,
These indexers are not clustered. This numbers represent performance that is based on an indexer that meets the reference hardware specifications as shown in the "Reference Hardware" topic in this manual.
We are working on getting performance figures for clustered environments. When we have those figures and can publish them, they will be added here. Thank you for your patience.
Are these indexers clustered? If so, what are the assumed replica and search factors? If not, how does clustering affect the count?
What is the definition of total users? Is it the number of concurrent users running real time search?
If one user creates 5 dashboards and each dashboard can have 10 real time panels. How many users is it? one? 50?
Hi Pgadhari, this documentation provides general guidelines. Questions as specific as this are beyond the scope of what we can cover here. We suggest that you contact your account representative for guidance, file a customer support ticket, or reach out to your fellow users on the Splunk Answers community (https://answers.splunk.com) for their advice based on similar requirements.