Cacti switching pollers from cmd.php to spine

[lk777]

Ubuntu 18.04
Cacti Version: 1.1.38 (Ubuntu package Version: 1.1.38+ds1-1)

I am new to Cacti and need some help.
I had some issues with cmd.php poller and decided to switch to the spine without knowing which one is better.
Now I get in cacti.log warnings like this:

Code: Select all

POLLER: Poller[Main Poller] WARNING: Cron is out of sync with the Poller Interval! The Poller Interval is '300' seconds, with a maximum of a '300' second Cron, but 310.0 seconds have passed since the last poll! 

Does the spine poller use the same cron job as cmd.php?

Code: Select all

/usr/share/cacti/site/poller.php

What poller is recommended to use?

I have found this https://github.com/Cacti/cacti/issues/ ... -388581494 issue and those error messages flooded my cacti.log.

[netniV]

The fact that 10 seconds later than asked the poller is kicking in, is an OS level issue and could be symptomatic that you don't have enough compute resource. The warning merely lets you know that outside of a few seconds, it's considered a problem if the poller is not run on time.

[lk777]

It periodically happens.
I am running it in a lxc/lxd container (Ubuntu 18.04) with some resource limitations:
limits.cpu: "2"
limits.memory: 3072MB

CPU load: 41% (1.60 (1 min) 1.91 (5 mins) 1.62 (15 mins))

Real memory: 24% ( 699.53 MB used / 539.72 MB cached / 2.86 GB total )

Virtual memory: 20% ( 571.68 MB used / 2.86 GB total )

Local disk space: 9% ( 27.68 GB used / 270.41 GB free / 298.09 GB total )

[netniV]

We don't control cron, that is an os level item. You may want to google "why is my cron delayed" or something like that to see if you can find answers about it.

[TheWitness]

netniV is correct. I've seen cron get sloppy especially under high load. For the times it did not trigger properly, check the cron log in /var/log, and see if it started at the right time. Another case would be that it started at the right time, but something blocked the php script from loading in a timely fashion. This might happen under very high I/O load, where something like boost is not being used and the php files that needed to be loaded could not be accessed due to I/O contention. The best solution for that would be to put your RRDfiles on separate disk, or just to timply use SSD or Flash/NVMe. Both NVMe and PCIe flash are always super fast, and cheap these days.