Around 100% cpu usage constantly
-
@Tom-Elliott got it fixed, it’s embarrassing for myself, mysql wasn’t rechable outside 127.0.0.1, some automatic installed security patch (i have this enabled) must caused it (it worked before) i changed the bind in my.cnf away from 127.0.0.1 to 0.0.0.0 you can also use machines current ip address on eth you are using. 0.0.0.0 binds to every network device.
No need for any postprocessing script
Just an idea, the installer could check the bind address while installing/updating and warn if bind is 127.0.0.1 or localhost.
EDIT:
Not fully solved my fog master is now burning, maybe 0.0.0.0 is not making it reachable to 127.0.0.1 (localhost)… i get back
ok that was not the problem, 0.0.0.0 really binds all access worked via mysql client, so i restarted services on the fog master with the script and it worked, i will try reboots and so on…Regards X23
-
@Wayne-Workman ok we can do this later
i did the following and it helped.
to installfog.sh at last line i added a call to restart_services.sh
additionally i added (as root) to cron (crontab -e) a call to restart_services.sh, use @reboot in front if the crontab line.Regards X23
-
Hi, after thinking it is fixed, i found this that morning:
Now the Multicast Service is burning like hell.
After another service restart via script it’s silent again, i will report back tomorrow morning if the hell comes back.Regards X23
-
@x23piracy just a guess that this goes crazy when updating.
-
@Tom-Elliott said in Around 100% cpu usage constantly:
@x23piracy just a guess that this goes crazy when updating.
That’s the case for me.
-
I’ve added some code in hopes to prevent runaway services such as this. With any luck the 100% cpu do to FOG services will be no more.
The Defaults, in case of issues:
FOGImageReplicator = 600 seconds (10 Minutes) FOGSnapinReplicator = 600 seconds (10 Minutes) FOGPingHosts = 300 seconds (5 Minutes) FOGScheduler = 60 seconds (1 Minute) FOGMulticastManager = 10 seconds
The writing to log files isn’t as important as the timing. It’s the timing that’s causing the run away CPU cycles as they’re running infinitely. Without a sleep to slow it all down, the services will keep doing work without a break, causing the spikes you’re describing.
-
Just updated both the fog-server and the fog-node to 7945 on debian 8 both. Nothing has changed I am afraid. The fog server runs fine but the storage node is at a constant 100% processor load. The 4 FOG services (ImageReplicator etc) keep using every processor cycle they can get.
-
@coco65 Run the script as it was designed earlier.
service FOGMulticastManager stop && sleep 5 && service FOGMulticastManager start service FOGPingHosts stop && sleep 5 && service FOGPingHosts start service FOGImageReplicator stop && sleep 5 && service FOGImageReplicator start service FOGSnapinReplicator stop && sleep 5 && service FOGSnapinReplicator start service FOGScheduler stop && sleep 5 && service FOGScheduler start
OR:
systemctl stop FOGMulticastManager && sleep 5 && systemctl start FOGMulticastManager systemctl stop FOGPingHosts && sleep 5 && systemctl start FOGPingHosts systemctl stop FOGImageReplicator && sleep 5 && systemctl start FOGImageReplicator systemctl stop FOGSnapinReplicator && sleep 5 && systemctl start FOGSnapinReplicator systemctl stop FOGScheduler && sleep 5 && systemctl start FOGScheduler
This is going to make sure the services have enough time to restart. The Installer appears to not satisfy the “timing” properly.
-
@Tom-Elliott : Thank you that works (the second version with systemctrl)
-
That’s why I post both. I have no idea what type your system is going to use so I just brute force them all.
In either case, this shouldn’t be a problem even on subsequent updates now.