When I first switched from the cmd.php poller to the cactid poller, I had no idea how many threads I should set. So I picked a nice round number of 10.
Big boo boo. Although the cactid poller seemed to be working, it would "orphan" perl, cactid, and php processes "occasionally". I would watch it for 15 or 20 minutes, and all would be fine. However, when I let it run over night, there would invariably be a few stranded processes either orphaned, or gone zombie.
When I dialed the number of cactid threads back to 3 or 4, things would function normally.
So, I guess the rule should be to start out small, and increase gradually, while watching the amount of time it takes the poller to run.
In my case, there were no significant time differences between 3 and 4 threads, so I have left it at 3, and it all seems to function well.
cactid: too many threads observation
Moderators: Developers, Moderators
cactid: too many threads observation
---------
The Glue Guy
The Glue Guy
Hi,
We've also noticed some similar behaviour, but we just run a scheduled job each night to kill off any processes that are 'hanging around'.
Using the 'pskill.exe' utillity from:
http://www.sysinternals.com/Utilities/PsKill.html
We just run a batch file that does:
OK, it's not pretty, but it gets the job done. Just schedule it for a few minutes after your regular polling interval.
3 or 4 Pollers may be OK for now, but as you ramp up the load on your Cacti system, you may find that you need to increase the number of Poller Processes.
Graham.
We've also noticed some similar behaviour, but we just run a scheduled job each night to kill off any processes that are 'hanging around'.
Using the 'pskill.exe' utillity from:
http://www.sysinternals.com/Utilities/PsKill.html
We just run a batch file that does:
Code: Select all
pskill.exe cactid.exe
pskill.exe php-win.exe
3 or 4 Pollers may be OK for now, but as you ramp up the load on your Cacti system, you may find that you need to increase the number of Poller Processes.
Graham.
Not sure if that's true.
We ran several iterations at both 3 threads and 4 threads, and they both run in about the same amount of time (~~ 100 monitored end points, and about 10 data elements per end point for ~~ 1000 monitored values).
Both take approximately the same amount of time. This indicates (to me) that the extra thread(s) take enough resources to null the effect of parallelism. This is on a uni-processor system with 2GB of memory. It's possible (probable even) that if you have a multi-processor system that you could take advantage of a few more threads.
So maybe the observation could be re-worded that 3-4 threads per CPU is a good number.
Anyone using cacti on a system with multiple CPUs? Would love to hear your experiences on this issue.
Guess the old addage is still true.
YMMV
bp
We ran several iterations at both 3 threads and 4 threads, and they both run in about the same amount of time (~~ 100 monitored end points, and about 10 data elements per end point for ~~ 1000 monitored values).
Both take approximately the same amount of time. This indicates (to me) that the extra thread(s) take enough resources to null the effect of parallelism. This is on a uni-processor system with 2GB of memory. It's possible (probable even) that if you have a multi-processor system that you could take advantage of a few more threads.
So maybe the observation could be re-worded that 3-4 threads per CPU is a good number.
Anyone using cacti on a system with multiple CPUs? Would love to hear your experiences on this issue.
Guess the old addage is still true.
YMMV
bp
---------
The Glue Guy
The Glue Guy
Who is online
Users browsing this forum: No registered users and 1 guest