We have Splunk 6.2, and we have a dashboard that utilizes 9 real-time searches and 4 historical searches. On both Chrome and Firefox, the dashboard causes the browser to crash intermittently throughout the day.
Is there anything that can be done to alleviate this issue? We'd like to keep the dashboard running throughout the day in our office, and this issue is preventing us from doing so.
1: upgrade to the latest version (there are big improvements in parallelization).
2: stop using real-time searches (they probably are not working the way you expect anyway).
It is too varied but I would be happy to come in on a 1 day contract to explore it with you. It may suffice to say that in all of my work with clients, I have never seen a real-time search implementation that was working as desired and in the end, as we explored the requirements, we always used something non-real-time that was more than good enough, so that we could avoid the calamitous downsides of real-time.
The only way to "make real-time work" is to mis-timestamp your events, which obviously, most people are unwilling to do.
I downvoted this post because you are using answers to advertise your services. please don't do this in the future.
Would it have been "OK" to say something like this:
You should see if you can hire a Splunk consultant for a couple of days to health-check your real-time searches because it is too complicated to go through in this forum
I was NOT trying to sell my services (I am plenty busy) but I was trying to give him a viable option because I think his dashboard is probably a ticking time-bomb on multiple fronts and it is not practical to unwrap it here.
I feel we would be better served to call this out as failures in design, not bad user behavior. Ideally, Splunk should NEVER cause the client to crash.
When there is no more RAM, if ANY process running on the machine is not 100% bug free as regards memory-management, you will crash everything. So the memory-management problem could be ANYWHERE (in any running process) but the precipitating factor causing all RAM to be used is the real-time search load.
IMHO, if somebody has a legitimate
real-time requirement, then Splunk is the wrong tool for the job.
This is because Splunk is "too literal" (this is a VERY good thing) as regards
_time and because there is always latency everywhere in everything. The only way to claim to be "real-time" is to gloss over all latencies and pretend that things happened later than they really did. If Splunk had a
pseudo-real-time mode that worked on
_indextime then that would be something else entirely. I do not like to tell my data to lie to me; and I don't help my clients to tell their data to lie to them, either.