1590 Appliance: Host Capacity Limits and CoreXL Configuration Check

[jennyado]

Hi everyone,

We recently experienced an issue with an SMB appliance where users reported failures with internal applications. As a first action, we performed a reboot on the device, which immediately restored services and resolved the issue.

After the reboot, we gathered diagnostic information, including the Dr. Spark report. In the report, we noticed the following:

1️⃣ CoreDumps:

Test info:
Userspace core found and was created on Apr 24 09:16, you can collect this core file in /logs/core.

I’m wondering — could this CoreDump affect the operation of the SMB?
The reason I ask is because the TAC suggested this file might be related to the issue, but I don’t fully understand how it could have caused problems if it was generated almost a month ago and the incident happened just two days ago.

2️⃣ CoreXL and Dispatchers test:

The numbers of CoreXL instances, dispatchers, and cores is incorrect. They should hold the following:
#CoreXL instances + #Dispatchers = #Cores
or
#CoreXL instances = #Dispatchers = #Cores
On this gateway: #CoreXL instances = 4, #Dispatchers = 10, #Cores = 4.

Is there any official documentation explaining how this should be configured on SMB appliances, or should we consider adjusting this setup?
Would appreciate some guidance or a best practices reference for this scenario.

3️⃣ Connected Hosts test:

Test failed. Error with connected hosts: too many.
Number of hosts: 1879
Hardware model: 1590

Could this test result mean that the number of connected hosts has exceeded the supported capacity for this hardware model (1590)?
Is there a recommended maximum number of hosts this model can reliably handle before it starts affecting performance or stability?

---

Any advice, insights, or documentation references you could share would be greatly appreciated!

Thanks in advance!

[Chris_Atkinson]

Which firmware / build is used with this appliance, did TAC recommend sk183290?

[jennyado]

It has R81.10.10 (996002993).

About TAC, they suspects a core dump on the appliance may have impacted connectivity. It’s safe to delete this file, along with messages, syslog messages, and upgrade images. After cleanup, it’s recommended to monitor the appliance for a few days.

I understand a core dump is generated when a process crashes, but I’m trying to figure out how this core dump could have affected the appliance’s performance to the point of impacting internal services. I also noticed that the /pfrm2.0 partition is at 88% usage — could this be related to the issue as well? Not sure if both things are connected, and I’d appreciate any insight.

/dev/mmcblk1p6 709296 579668 78020 88% /pfrm2.03

I'll check the sk183290 that you shared me

[jennyado]

Do you know how much resources the sk183290 might consume? The SMB appliance currently has around 500 MB of free memory, maybe a bit less. I'm wondering if running this would have any noticeable impact.

[the_rock]

I just tested it in the lab and did not notice any memory usage at all, seems like a pretty light script.

Andy

[jennyado]

Thanks so much for trying it out. I'll check to run the script and see what information it gives me.

[the_rock]

Yea, no problem. Did not give much in the lab, but I hope helps in your case.

Andy

[the_rock]

I did some online searching, as I could not find an answer in 1590 data sheet link, says this device can handle about 200 users.

Andy

[jennyado]

Does this test refer to VPN connected users or this refer to connections in the SMB?

 Connected Hosts test:

Test failed. Error with connected hosts: too many.
Number of hosts: 1879
Hardware model: 1590

[the_rock]

Logically, to me anyway, seems like users related.

Andy

[the_rock]

Also, hope below helps.

Andy

https://community.checkpoint.com/t5/SMB-Gateways-Spark/No-of-users/td-p/78976

[sigal]

Hi,
Regarding the CoreXL and Dispatchers test, please refer to sk174423. 
Based on the error and your appliance type, you should probably set KERN_INSTANCE_NUM to 4.

Thanks. 

[PhoneBoy]

Historically speaking, SMB appliances haven’t required tuning the SND/Worker split.
I suspect this is a result of the number of cores (4 or less) where adjusting that split won’t make much of a difference.

The newer, higher-end SMB appliances have more cores where some tuning might be needed and may improve performance in certain scenarios.
However, I would leave the settings at their defaults unless you are persistently seeing high utilization on SND cores.

Not sure if the SMB version of R82 will include Dynamic Balancing, which would handle tuning the SND/Worker split on the fly as needed (versus a static split).