English Forums > Zenarmor (Sensei)
why is eastpect locked to a single core
johndchch:
whilst troubleshooting very uneven core loading I noticed that each eastpect instance seems to be locked to a single core
e.g.
cpuset -g -p <pid of eastpect instancle 0>
pid 17862 mask: 1
pid 17862 domain policy: first-touch mask: 0
I presume this is done to either aid latency or to allow for a multiple interfaces ( and hence multiple eastpect instances )
question is - for a single LAN interface config ( so single eastpect instance ) would setting the mask to all available cores make more sense?
A few quick experiments changing the mask to all cores seems to improve the single core overloads I was seeing, and doesn't seem to affect performance in any negative manner
sy:
Hi,
Yes, Zenarmor performance will be better for high traffics with multicore support. It is on our roadmap and will be added next year.
mb:
Hi @johndchch,
We intentionally pin zenarmor to a dedicated core in order to prevent CPU context-switching overhead. Because if the process is wandering around CPU cores, we start to see CPU cache misses, which will in turn negatively impact performance.
Having said that, it's very interesting that you're seeing the opposite. Can you provide a bit more information? What is the CPU model? Is there a specific server hardware you're using?
johndchch:
it's running on a i7-6700 ( with a 1gbps internet connection ) - and yes, I expect pinning WOULD help on smaller/slower cpus ( especially ones with small L2/L3 ), guess it's one of those things where you had to make a call and obviously need to err on the side of acceptable performance on low powered systems
any chance you could expose the pin option in the UI or too esoteric to explain and too low a priority? right now I just have a cron job to check/reset the process
mb:
Hi @johndchch,
Makes sense, thanks.
Sure thing, I think we can introduce an option to the Interface Configuration Screen.
It's a bit late for 1.12, however let's see if we can ship with 1.13.
Navigation
[0] Message Index
[#] Next page
Go to full version