URL filtering blade (RAD process) causing high CPU tip

[the_rock]

Hey guys,

Just a quick tip, though Im sure most of you may know, referring to below post:

https://community.checkpoint.com/t5/Security-Gateways/High-CPU-on-Security-Gateway-caused-by-RAD-ser...

Customer tried value of 50000 in guidbeedit, no change, so once we did failover, all worked fine. I asked them to install jumbo 99 on the cluster (currently on jumbo 98).

mgmt -> R81.20 jumbo 99

gw cluster -> R81.20 jumbo 98

Btw, if its standalone or just a single gateway, usually cprestart would work, or reboot, but just keep in mind that since cpstop unloads the policy, there would be disruption for short time.

Something to keep in mind if you ever encounter RAD process causing high CPU.

Cheers,

Andy

[GigaYang]

Hi Andy,

As attach file. Thank you.

[the_rock]

K, so it is correct. I would probably open TAC case to look into it further.

Andy

[the_rock]

I would 100% take the advice of @Timothy_Hall . I feel if there is anyone out there who knows this stuff, its him. Man even wrote a section of the book about this topic : - )

Andy

[Timothy_Hall]

You have 9.8GB of memory available (not free) out of 32GB so you have plenty of memory; your firewall is not dipping into swap space and as such is not struggling for memory.   fwk0_dev_0 is expected to consume a large amount of memory as it is the lead process for all of your Firewall Worker Instance threads when the firewall is in USFW mode. While top is running hit SHIFT-H and you will be able to see all the individual fwk threads representing the worker instances in your CoreXL split, it looks like you did that in your second screenshot.   I don't see anything in your screenshots that is not expected behavior.

[GigaYang]

Thanks for the answers.
But what I don't understand is why all this happened after I adjusted the RAD settings.

[the_rock]

I get your point, for sure @GigaYang . Thats why I think having TAC verify would not be a bad idea.

Andy

[the_rock]

I think the only way to know 100% if process from the sk caused that issue would be to revert. Maybe its too coincidental, but we cant be certain.

Andy

[GigaYang]

Thanks

We have already set up TAC in the past few days.

Support has responded that this situation has nothing to do with sk182859. sk182859 has successfully solved our previous CPU overshoot problem.

Support is expected to conduct a remote inspection this afternoon, and I will report back here later.

[the_rock]

K, sounds good!

[the_rock]

Hey @GigaYang , any news after remote with TAC?

Andy

[GigaYang]

Hi Andy,
Thank you for your assistance.

Support believes that we have correctly implemented sk182859 and resolved the CPU issue caused by RAD Daemon.

But he thinks the memory problem is caused by increased traffic/connections. In our Rule Base, there is a rule (#24) that causes all subsequent rules to be executed in the F2F path. He also suspected that the problem might be caused by IPS.

However, none of these instructions can explain why memory usage increases immediately after executing sk182859 and remains at 75%. So he finally guessed that Memoey Leaking might be the last reason and suggested us sk35496. However, as far as I understand, Memoey Leaking usually increases slowly, and no Memoey Leaking problem was detected in the HCP Report.

In addition, there is currently no Heavy Traffic connection in our system.

Finally, the memory usage status for the past month is provided.

[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