Some CPU with high Interrupts value and some with low Interrupts value

[Tom_Bosch]

Hello,

We are seeing following output with CPVIEW on R80.40. With the first 17 CPUs the number of interrupts is high. The following 23 CPUs have very low values at the interrupts column. Does anyone have an idea what the problem is?

[PhoneBoy]

I assume it's because the interfaces associated with the SND/FWK processes are processing the majority of the traffic.
Super Seven command output, please?
https://community.checkpoint.com/t5/General-Topics/Super-Seven-Performance-Assessment-Commands-s7pac...

[Tom_Bosch]

Output of Super Seven Performance Assessment Commands.

Command 1:  fwaccel stat

Command 2: fwaccel stats -s

1% --> Accelerated conns/Total conns is very low?

Command 3: grep -c  ^processor  /proc/cpuinfo

/sbin/cpuinfo:

Command 4: fw ctl affinity -l -r

Command 5: netstat -ni

A lot RX-DRP frames on Mgmt interface? 0,25% (should be <0,1%)?

Command 6: fw ctl multik stat

Command 7: cpstat os -f multi_cpu -o 1

Command 7: cpstat os -f multi_cpu -o 1

[Timothy_Hall]

I've seen an odd distribution of Interrupts like that before and it doesn't indicate a problem.  I suspect the Linux OS has allocated these processors to handle hardware interrupts (hi% in top output) from the NICs and other devices, which are separate from soft interrupts (si% in top - SoftIRQ among others) that are processed only by SND cores.

Yes the number of RX-DRPs on your Mgmt interface is too high, because Multi-Queue is not allowed on the defined management interface in R80.40; there is no way to enable it on the Mgmt interface other than to move your management interface out of the way.  I recently ran into this and just posted this update to the Max Power 2020 addendum thread:

p. 221: If possible, do not set an R80.40's firewall’s management interface to a NIC that is carrying a heavy amount of production traffic to avoid possible frame loss (RX-DRP as shown by command netstat -ni) caused by the lack of Multi-Queue on that interface. If the management interface has been changed from a busy production interface and Multi-Queue is still not active on that busy interface (use the expert mode mq_mng –o –vv command to check this) see this SK: sk167200: Multi-queue state is "off" when changing the management interface.  It appears that the restriction blocking the activation Multi-Queue on the firewall's management interface has been lifted in R81.

Don't worry about the low Accelerated Conns percentage, it just means that connection rule matches are not being cached/templated by SecureXL.   Many blades can cause this effect including Anti-bot.

[Prashant_YADAV1]

Hello,

i have recently faced this issue and according to checkpoint tac this is a issue in cpview reporting and should be fix in Take 92.

Please see the attachment