- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
So like most of my painfully specific questions this will probably need to be answered by R&D. Tagging @PhoneBoy
I'm doing my monthly updates to my Gateway Performance Optimization Course, and I'm curious about the role of the "Thread Blocker" and under what circumstances it might need to be disabled. As I understand so far it is some kind of watchdog to ensure that a USFW-based fwk worker instance does not monopolize its CPU while handling a long-running thread by basically blocking that hogging thread, and giving some other ones a fair chance at that CPU. This feature seems to be trying to avoid a kernel "soft lockup" type situation that could occur when the worker instances were still located in the kernel, and did not relinquish the CPU in a timely fashion. However some other things I've read are that it is purely "monitoring only" and does not actively do anything other than create logs. This SK does provide some insight but I'm specifically curious about what kinds of situations/workloads (elephant flows?) would not play well with this feature that is enabled by default:
Also @Thomas_Eichelbu posted some interesting speculation & questions about the Thread Blocker in a prior thread that don't appear to have been answered:
Thanks!
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY