BOOST doesn't improve poll time

[amitayb]

Hi,
I've 2 cacti servers. In 1 server boost really improves polling time, on other server no improve at all.

serverA Based on VM
Linux RHEL
CPU: 8 cores
Mem: 12GB
Cacti 0.8.8A
Boost 5.1

Last Run Statistics Time:38.3788 Method:spine Processes:15 Threads:30 Hosts:166 HostsPerProcess:12 DataSources:42168 RRDsProcessed:0
BOOST Runtime Statistics
Last Start Time: 2016-11-28 17:55:40
Last Run Duration: 8 minutes 52 seconds (15% of update frequency)
RRD Updates: 536954
Peak Poller Memory: 57.81 MBytes
Detailed Runtime Timers: RRDUpdates:536954 TotalTime:532 get_records:8.12 results_cycle:519.23 rrd_filename_and_template:3.74 rrd_lastupdate:51.62 rrdupdate:459.28 delete:1.18
Max Poller Memory Allowed: 2048 MBytes

ServerB based on VM
Linux RHEL
CPU: 34 cores
Mem: 34GB
Cacti 0.8.8F
Boost 5.1
Last Run Statistics Time:227.0010 Method:spine Processes:6 Threads:5 Hosts:817 HostsPerProcess:137 DataSources:65961 RRDsProcessed:0
Runtime Statistics
Last Start Time: 2016-11-28 17:49:01
Last Run Duration: 26 seconds (1% of update frequency)
RRD Updates: 460206
Peak Poller Memory: 58.89 MBytes
Detailed Runtime Timers: RRDUpdates:460206 TotalTime:27 get_records:5.88 results_cycle:19.28 rrd_filename_and_template:5.35 rrd_lastupdate:1.33 rrdupdate:6.17 delete:0.7
Max Poller Memory Allowed: 2048 MBytes

on server A: DataSources:42168 takes 38sec.
on server B: DataSources:65961 takes 227sec

server B has much more mem and CPU.
any ideas why my boost isnt much effecting my serverB?
I've tried to increase Processes & Threads on server B. It makes poll time to take longer.

[amitayb]

Hi,
I've tried to change in serverB the poller parameters as in server a.
in this way I have 0idle CPU. the hole GUI freeze.

where should I check to solve this issue?

[amitayb]

Hi,
Any ideas what to check?

[cigamit]

Boost is made to speed up polling for people with slow disks, your problem seems to be something else (your 2nd server seems to have way faster disks based upon RRDUpdate time).

Its not just about the number of datasources, its about the type of data source too and how long each of those hosts takes to respond. Honestly I am surprised your first system isn't overloading itself, that is way too many processes / threads. You have 450 threads fighting for CPU (you also don't state whether those CPUs have Hyperthreading). Your second one should be able to handle way more processes / threads. I generally do 1 process per core (2 if hyperthreading) and 10 -12 threads per process depending on the overall type of devices I am polling. Network gear and Linux devices generally respond a lot faster than Windows devices (and if you are querying via WMI, you can also forget about any type of speedy finish). If devices are slow to respond, I add more threads so that you can be processing more data while waiting on results. Also, if you are using a lot of scripts, make sure there are plenty of script servers running (another setting).

Also, is both the boost_poller_output table a memory table? You can also make the poller_output table a memory table too.

[amitayb]

Hi,
I'm monitoring lots of snmp, some php scripts.
I've change the parameters and im on 180 sec per poll cycle.
I'm only sampling network devices like routers and switches.

i thought I can have better perfomance according to my old system performance.

thanks for your time.

[browniebraun]

Keep in mind that a single host can cause such a high poller runtime. Take a look at your processes running every polling cycle. You will notice that most probably only a single polling process will remain while others have been completed pretty fast. Try to identify that host and change its polling parameters.
This will become much easier with Cacti 1.0.

Boost itself it is great if you need to decrease I/O waits caused by slow disks or the amount of data you have to update. (In my case I have more than 400GB of RRDfiles.)

Code: Select all

12/06/2016 08:22:51 AM - SYSTEM THOLD STATS: CPUTime:874 MaxRuntime:279 Tholds:135841 TotalHosts:2253 DownHosts:75 NewDownHosts:0 Processes: 14 completed, 4 running, 0 broken
12/06/2016 08:22:42 AM - SYSTEM STATS: Time:160.7313 Method:spine Processes:16 Threads:40 Hosts:2254 HostsPerProcess:141 DataSources:480698 RRDsProcessed:0
RRDUpdates:6193882 TotalTime:504 get_records:67.76 results_cycle:420.57 rrd_filename_and_template:128.21 rrd_lastupdate:22.34 rrdupdate:203.71 delete:7.64 timer_overhead:~6

Regards
-Andi