topic Re: SHC performance issue in Monitoring Splunk

SHC performance issue

chaitali_1994 — Sat, 06 Jun 2020 01:45:56 GMT

Hi ,

We have 3 search heads in our search head clustered environment,
first we saw Raft issues in the captain, then we had referred this document : https://docs.splunk.com/Documentation/Splunk/7.2.3/DistSearch/Handleraftissues even after that we are facing same issues like the captain is going down first and later on the members one by one.
We have also found one more error "child killed by signal 9"
Also there is some false error messages appearing in DMC regarding the shc is down, bring it back online ASAP to avoid service disruption.
Can anyone please help with resolving these issues as the search heads are going down abruptly?

Thanks in Advance!

Re: SHC performance issue

skalliger — Wed, 26 Jun 2019 19:33:33 GMT

Now that is not easy to troubleshoot without more information about your environment.

What are the specs of the SHs?
Are you running a lot of schedules searches? What's happening before they go down? Please take a look into the Monitoring Console (I suggest using it, it gives very good insight especially for troubleshooting issues) and analyze the SHC dashboards provided there.
what was the reason the processes got killed? Memory problems maybe?

Skalli

Re: SHC performance issue

jnudell_2 — Wed, 26 Jun 2019 19:50:02 GMT

SHC is a pretty complicated setup, and it's very finicky. If you're not familiar with operating and maintaining a SHC, it might be best to get Splunk Professional Services involved, or open a support ticket for your issue.

Re: SHC performance issue

DavidHourani — Thu, 27 Jun 2019 09:41:20 GMT

seems like a crash: child killed by signal 9 you'll need to reach out for support as this could be due to a bug. You're on 7.2.3 ?

Re: SHC performance issue

codebuilder — Thu, 27 Jun 2019 16:14:55 GMT

You need to increase memory on your SHC nodes, increase ulimit settings, or reduce memory consumption by Splunk.

When a process is killed by signal 9 that indicates that the kernel is protecting itself by killing processes that are consuming or reserving more memory than is available or allowed.