Unusual higher that average CPU

[r1der]

Greetings all, I am observing a higher than average CPU usage on one of our gateways.
We normally hover in the low CPU usage percentages, but yesterday I noticed we were hovering around 50% and staying there.
I looked at top -H and saw the rad_resp_slow_0, rad_resp_slow_1, and rad_resp_slow_2 processes using a lot of CPU. 
I'm afraid we're being attacked or something is going on, but I can't identify what is causing these. Is there a report or view in SmartConsole that can show me like blade usages perhaps? I'm not sure where to go from here now that I've identified processes using the CPU. 

According to support (SR#6-0004255887), this is the Resource Awareness Daemon, and helps with managing anti-malware policies, etc. I was told it could be due to complex rulebase or policy operations, however I don't recall changing or adding any new policies.
My only guess would be IPS? 

Should I do this?
 Solved: High CPU on Security Gateway caused by RAD service... - Check Point CheckMates

Where would you start?

Thanks!

[the_rock]

Hey mate,

See if below discussion helps.

Andy

https://community.checkpoint.com/t5/Security-Gateways/URL-filtering-blade-RAD-process-causing-high-C...

[the_rock]

You could try disable IPS, does not hurt, and see if it helps. Just uncheck the blade, install policy.

Andy

[r1der]

Thanks, I'm going to go through that post.

*Update* I was curious if moving to the standby gateway will help. So I performed admin failover and I am back down to 4% ~ but I'm not sure what was happening with the other gateway. I'm going to let it sit for a bit to see if CPU starts increasing again, and then move it back to the gateway that was having high cpu.

[the_rock]

Thats how I fixed it last few times...failover, leave it for a day, fail back...done.

Andy

[Chris_Atkinson]

Careful a failover may simply have temporarily masked the condition...

Which version/JHF is used? Note there are some worthwhile fixes in R81.20 JHF T99 that may be relevant.

[the_rock]

Good point Chris. Thats why I said probably not a bad idea to leave the other member as master day or two, just to be on a safe side and then fail back.

Andy

[r1der]

Hi Chris, yes, I agree it probably is just temporarily masking the issue.
Yesterday and today, I saw the active gateway hover higher than normal CPU. 
We're on R81.10 Jumbo Hotfix Take 172. @the_rock I am upgrading SMS/GW1 to R81.10 Take 174 and failing over tomorrow.
I have a support case with TAC and they also advise to update based on this:
List of All Resolved Issues and New Features in R81.10 Jumbo Hotfix Accumulator

PRJ-58089, PMTR-109845

Security Gateway

When the autodebug feature is enabled, the RAD service may consume high CPU and trigger "RAD service not available" alert logs.

[the_rock]

Good idea...that take shows recommended anyway.

Andy

[the_rock]

Hey mate,

Any luck with this?

Best,

Andy

[r1der · Accepted solution]

So far Take 174 for R81.10 seems to be the fix. Still monitoring of course, but looks good.
(Flat line due to switching to secondary gateway) but you see the CPU usage creeping up again towards May1.

[the_rock]

Great job!

[the_rock]

For what its worth, I now suggest to everyone based on my extensive lab testing, mgmt on R82, gateways R81.20 jumbo 99, works real well. I would not bother with gateways to R82 yet, at least until its recommended version, which I believe will be soon, but even then, would give it month or two.

Hope that helps.

Andy

[maad-pul]

Hi All,

When patched to R81.20 TAKE99  (which was done yesterdag) is SK182859 relevant then?

I still see som problems in Anti-Bot & Anti-Virus Blade, but much fewer then before patching.

Should I still implement this, the "solution" based on this threat? Edit "rad_max_concurrent_requests" from 2500 to 5000"
https://community.checkpoint.com/t5/Security-Gateways/High-CPU-on-Security-Gateway-caused-by-RAD-ser...

PRJ-58090, PMTR-109845

Security Gateway

When the autodebug feature is enabled, the RAD service may consume high CPU and trigger "RAD service not available" alert logs.

/Mattias

[r1der]

Hey, sorry I didn't get notifications for this and haven't logged on here in a while. Hopefully you have your issues resolved by now. 

I didn't have to edit "rad_max_concurrent_requests", since patching fixed my issue. I'd start a TAC Case just to be sure if I were you.