EVA ICS doesn’t use thread pools in core, number of threads is always fixed (except LM PLC macros), grows together with node configuration, and should be controlled by system administrator/integrator. Majority threads “sleep” until they get an event and don’t produce additional load.
After controller start, core launches several system threads (garbage collectors etc.), plus threads for each item:
- Two update threads (update scheduler + update processor) per each unit, sensor and lvar
- One action thread per each unit
- Two update threads for PHI module, if loaded with update=X parameter
- One notification queue thread for each notifier
- One thread for UC UDP API, one thread for UC SNMP trap handler (if enabled).
- LM PLC launches a single thread which handles queue for scheduled macro exections. After the execution, each macro has its own thread, number of threads for macros isn’t limited by PLC.
- Also, each LM PLC logic cycle has own thread as well
- If MQTT transport is used for API calls between nodes – one thread per API call (max lifetime = server.timeout)
The following threads are started in pools and limited with the corresponding pool size:
- webapi.thread_pool = 15 (default) – number of threads serving HTTP API requests
- server.reactor_thread_pool = 15 (default) – number of threads serving Modbus slave in UC
In real life, there’s no problem for tiny ARM-based industrial computers to handle 100-200 items per node, including LM PLC event processing and without any significant CPU load. However, any system can be overloaded, if you try.
As it was already said, majority threads “sleep” until event. If node doesn’t perform any complex data processing but CPU load is high, here are few tips to reduce it:
- increase update intervals for items and loaded PHIs
- decrease number of items / move items to additional nodes
- optimize logic of LM PLC macros / move complex data processing out