I do not think you are right, Herr Swe.
Adam.
Sent from BlueMail
On 17 Jul 2018, 12:25, at 12:25, Markus Klock markus@best-practice.se wrote:
The same reason you recommend keeping polling-time as close to 300s as possible. When doing this you can run the poller with much fewer threads needed for polling. Instead of starting every 5min with 128 threads you can do 32 threads every 1min which will be a lot less CPU context switches and much lower IO spikes for the system. The system will be under little load all the time instead of one huge spike and then idle for 150s :) /Markus
2018-07-17 20:33 GMT+02:00 Adam Armstrong adama@memetic.org:
But why though? :D
The poller-wrapper's entire purpose is to do what you're doing here
:D
adam.
On 2018-07-12 00:36, Markus Klock wrote:
Yeah, I usually even out the server load by splitting the number of devices in 5 and start the polling of them 1 minute apart with cron like this: 0-59/5 * * * * observium /opt/observium/observium-wrapper polling -i 5 -n 0 >> /dev/null 2>&1 1-59/5 * * * * observium /opt/observium/observium-wrapper polling -i 5 -n 1 >> /dev/null 2>&1 2-59/5 * * * * observium /opt/observium/observium-wrapper polling -i 5 -n 2 >> /dev/null 2>&1 3-59/5 * * * * observium /opt/observium/observium-wrapper polling -i 5 -n 3 >> /dev/null 2>&1 4-59/5 * * * * observium /opt/observium/observium-wrapper polling -i 5 -n 4 >> /dev/null 2>&1
This makes it work with a lot fewer threads and the load on disk and database is much lower as only 1/5 of the data needs to be
progressed
at the same time.
/Markus
2018-07-12 7:09 GMT+02:00 Adam Armstrong adama@memetic.org:
You should probably decide threads to even out the load. The goal is
to be as close to 300 seconds as you can manage, else you'll get spiky io and myself load.
Adam.
Sent from BlueMail [2]
On 11 Jul 2018, at 07:18, "Balistreri, Thomas C - DOC" thomas.balistreri@wisconsin.gov wrote:
Wow! What hardware are you using? Where are your devices located?
I’m running about 90s for around 900 devices (21,000+ ports), but I have to transverse WAN links for 95% of it.
Tommy
FROM: observium [mailto:observium-bounces@observium.org] ON BEHALF OF Markus Klock SENT: Wednesday, July 11, 2018 8:57 AM TO: Observium Network Observation System observium@observium.org SUBJECT: [Observium] New record?
Hi guys,
just wanted to show the new Observium I deployed for a customer this week :)
Everything polled from one single server without problems (pollingtime is about 140s for all devices)
Big thanks to Mike who helped me identify and fix a scaling issue when running a huge amount of threads. (if you run an Observium-install that runs poller-wrapper with 100+ threads you should check out r9333)
/Markus
CONFIDENTIALITY NOTICE: This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is only for the use of the individual or entity to whom this electronic mail transmission was intended. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please immediately contact the sender and delete the message. Thank you.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2] http://www.bluemail.me/r?b=13187 _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium