- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- R81 Hyperthreading Support Recommendation
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
R81 Hyperthreading Support Recommendation
Hello,
Does anyone have any up-to-date information related to hyperthreading support on R81.10 deployed on open servers?
Is it recommended to enabled it if your hardware supports it?
Have single-threaded processes been redeveloped as multi-threaded processes. If not, will those single-threaded processes still be performance impacted if hyper-threading is enabled?
One new feature introduced in R81e, concurrent policy installs (up to 5 running with additional installs queued), indicates the introduction of multi-threaded processes.
Regards,
Simon
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Although it's possible to enable hyperthreading on Management appliances or open servers, we (in R&D) do not recommend it.
Many flows in the Management code support multithreading or multi-process computation. For this reason, the Management server benefits from powerful machines with many cores. However, hyperthreading tries to emulate double the number of cores, but these are not real physical cores. Depending on the type of operations, wait for IO or even some specific flows that are still single threaded, you might not get a benefit from it.
When we tested hyperthreading in our performance labs, we did not see an improvement and we even saw negative performance impact in many flows.
It's possible that in future versions / HW we will revisit this decision, but at this point we recommend to keep hyperthreading off on Management machines. This is also the default setting for the latest released 600 / 6000L / 6000XL appliances.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SMT support is mostly relevant to GWs and not MGMT. Also, your reference to policy installation is erroneous, afaik.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mostly relevant to GWs pre R81 yes, But has anything changed in this regard in R81.
Which part is erroneous? I've previously been informed the concurrent limit for policy install per management domain is 5 and any beyond that are queued. If that's what you were referring to specifically, it's not really the focus of my question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Last time I checked, there is no SMT support changes.
Concerning policy installation, yes, we support up to 5 simultaneous installations. These are not done by a single process, though.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Whenever I've asked about whether SMT/Hyperthreading on an SMS/MDS will improve performance, the answer I've always gotten from Check Point is "it depends". According to them some workloads will improve and some will suffer with SMT enabled.
However given that an SMS is usually acting as a log server (and perhaps even implementing SmartEvent) there is going to be a lot of waiting around for disk I/O events which SMT would seem to jive nicely with, as in letting an execution thread that just blocked waiting for disk I/O relinquish the CPU thread for another nonblocked thread of execution that can jump on that processor.
But the real test is whether SMT is enabled by default on the Smart-1 appliances sold by Check Point. In every case when I have remembered to check the SMT status on a customer's Smart-1 SMS, SMT has always been enabled. However I haven't done this check recently and definitely not on the newer Smart-1's, so if anyone reading this has one of the following Smart-1 models could you please run the command cat /sys/devices/system/cpu/smt/active (proper command will be cat /proc/smt_status for Gaia 2.6.18) and post the result:
- Smart-1 600
- Smart-1 625
- Smart-1 6000
- Smart-1 6000 XL
My guess is SMT will be enabled on all of these by default, so SMT should probably be enabled on open hardware SMS's; there are no licensing limits for number of cores utilized on SMS/MDS's.
March 27th with sessions for both the EMEA and Americas time zones
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Although it's possible to enable hyperthreading on Management appliances or open servers, we (in R&D) do not recommend it.
Many flows in the Management code support multithreading or multi-process computation. For this reason, the Management server benefits from powerful machines with many cores. However, hyperthreading tries to emulate double the number of cores, but these are not real physical cores. Depending on the type of operations, wait for IO or even some specific flows that are still single threaded, you might not get a benefit from it.
When we tested hyperthreading in our performance labs, we did not see an improvement and we even saw negative performance impact in many flows.
It's possible that in future versions / HW we will revisit this decision, but at this point we recommend to keep hyperthreading off on Management machines. This is also the default setting for the latest released 600 / 6000L / 6000XL appliances.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the clarification Tomer.
March 27th with sessions for both the EMEA and Americas time zones
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks @Tomer_Noy
