No changes were made to other components of the platform - we use librenms service poller.
Is that anything obvious you could think of in the new release that would cause such dramatic poller slowdown? It looks like all this extra time comes from ‘ports’ component…
I reverted to the ‘legacy’ poller-service.py service (from librenms-service.py) and it performs much better.
I have actually realized I raised something similar ages ago:
It looks like the problem is still there to some degree - and performance of librenms-service.py got somehow worse in recent releases.
Seems like this thing is getting confused by Nexus routers as well a bunch of UCS 6300 FIs - disabling them brings polling back to acceptable levels.
This project could really use high-performance poller with in-flight window tuning on per-device basis, like the AKIPS one (AKIPS - Network Monitoring Software) - I would have contributed the code if I had any idea how to implement that …
Tested from services v2 to crontab, performances are worse.
Don’t want to test poller-service.py - v1 services - because a bug can DoS equipments due mysql/mariadb.
May be playing with numbers of worker could help also
I don’t know if this is related to the issue the OP is having with the poller, but for me the poller performance degraded at around April 2019.
This can be traced back to the 1.50 or 1.50.1 release.