SmartConsole R80.30EA high CPU utilization

[Vladimir]

After about 30 minutes and, (if relevant), installation of the Geo Policy, my laptop is ready for liftoff:

[Timothy_Hall]

In R80+ Management most of the "heavy lifting" occurs on the SMS cores, and the SmartConsole software isn't responsible for much other than displaying what the SMS tells it to (at least compared to the R77.XX SmartDashboard).  Any time you experience issues with the SmartConsole software itself, my recommendations always are:

1)   Obtain the latest version of the SmartConsole software, most sites I see are still running the initial version of SmartConsole code provided with the vanilla version of a particular release:

Check_Point_SmartConsole_and_SmartDomain_Manager_R77.30_T204_Windows.exe

sk110892: R77.30 SmartConsole and SmartDomain Manager for Windows 10

sk119612: R80.10 SmartConsole Releases

sk137593: R80.20 SmartConsole Releases

2) Make sure your Windows system meets the requirements for the SmartConsole software, which is at least a Intel Pentium Processor E2140 or 2 GHz equivalent processor and 4GB of RAM (very important).  Windows 7-10.

3) The SmartConsole software is heavily dependent on the .NET framework from Microsoft, via Windows Update make sure your .NET libraries are up to date, particularly on older OS versions like Windows 7.

4) If you find a reproducible functionality, stability, or performance issue first enable SmartConsole debugging under Manage & Settings...Preferences...Start Debugging then reproduce the issue.  Once complete, return to this screen and click Stop debugging and you will be informed where the debug file was written.  Looking through this debug can provide valuable insight into what the SmartConsole software is having issues with, or can be provided to TAC.

5) If trying to use the SmartConsole software via an RDP Session and stability or performance issues are experienced, see these SKs:

sk124573: SmartConsole stops working when connecting directly with RDP

sk123734: SmartConsole slow rendering when running through Remote Desktop

6) If there is high latency between the SmartConsole and the SMS, the SmartConsole software will respond slowly.  This effect starts to become noticeable at latencies greater than 100ms, regardless of the amount of actual bandwidth available.  The interactions between the SmartConsole and SMS seem to be very sequential (operation,ack,operation,ack), and apparently lack the ability to parallelize or pipeline operations.  The only workaround for this is to establish a jump box running the SmartConsole close to the SMS where latency is low, then RDPing into the jump box to use SmartConsole.  Just be sure to see #5 above if using RDP.

[Vladimir]

@Timothy_Hall , thank you for the pointers, but in my case:

1. SmartConsole is R80.30 EA T155, which is the only available version

2. Windows 10 is the Insider Build 18363, which is the latest

3. The laptop specs are:

    a. Processor Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz, 2801 Mhz, 4 Core(s), 8 Logical Processor(s)

    b. Installed Physical Memory (RAM) 32.0 GB

    c. HDD is a PCIe NVMe SSD

So it does not look like it is straining under load 🙂

So far, this is a brand new installation of R80.30EA with associated SmartConsole and it was a single instance of high CPU consumption on day one. I'll keep an eye on it and will report if this is a recurring issue.

Cheers,

Vladimir

[Ryan_St__Germai]

Either there is an issue with R80.30 smart console itself or it is possible since this is a laptop, thermal down-clocking is taking place. At the time of this high CPU load what is the clock of the cpu?

[Vladimir]

Hard to determine that retrospectively.

That being said, when it is plugged-n, it is configured to work in "Performance" mode, so it will not down-clock from the power saving perspective. As to thermal, the only app that caused the fans to whirl was the SmartConsole itself, so there would not have been a need for its power management to kick-in prior to that.

[Vladimir]

P.S. The only other process with notable CPU utilization (about 15%) was Windows Data Telemetry, used in the Insider Builds.

I've bagged it through the local policy and registry, just to make sure it will not be interfering in the future. I'll give it a week to see if the issue persists and post the findings here.