Around 100% cpu usage constantly

[fry_p]

Hi all,
Up until recently, my FOG server was running pretty well in my VMware environment. I am running into alarms now for CPU usage on my server. It is constantly showing 100% CPU usage on both VMware console and within Ubuntu. Here are my stats: I am running Ubuntu 14.04 with FOG trunk 7723 (just updated to 7725 to see if that helps). VMware with 4vcpus and 8 Gb of memory. Recently, rebooting helped for a little bit, but now it shoots up to 100 as soon as it is fully booted. I looked at system monitor and 4 FOG services were sitting at 20% CPU each. Should have taken a screenshot of that, but now Multicast Manager is the only one eating up resources. It is at 25% CPU. I do not really utilize Multicast in my environment nor am I actively running that task. See below for screenshots:

Interestingly enough, the dip you see is me deploying an image.

During the worst of it.

The remaining Process still using too much
Thanks,
Paul

[Tom Elliott]

Because Ubuntu, that’s why…

If you manually restart the services (full restart not the command line restart),

These things should clear up
Run these commands AS the root user. (sudo -i or sudo su -)

If Sysvinit:

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

If systemd (Unlikely if you’re on 14.04).

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

[fry_p]

@Tom-Elliott I noticed now that the multicast manager is the only service that seems to do this now after every upgrade. I am able to fix it with the commands you posted until the next upgrade. As you know, I upgrade with a script. Do you think it would help if I incorporated this into my script? If you think It’d help, I will try it. Is there a way to embed sudo -iinto the script? I’ve embedded my FogAdmin local account into the script, but I don’t know how to embed root. I know it’s probably bad practice to do that, but it would help a lot.

[Tom Elliott]

@fry_p i think you could just do sudo -c as it will run the commands as if it was run by root interactive, but without going into “interactive” mode of the shell. I’m not 100% sure though.

[Sebastian Roth]

@fry_p said in Around 100% cpu usage constantly:

Is there a way to embed sudo -iinto the script?

Maybe just run your script with sudo script.sh??

[fry_p]

@Sebastian-Roth I’m having trouble understanding. Anything I do besides manually putting in sudo -i then running the service restart, I get “permission denied”. Also, the sudo -c throws the same error. This is a tough one. Since I embed my fogadmin account into my script, I’d have to either change that to root credentials or somehow embed both. Right now it is still the MulticastManager doing it.

[fry_p]

@Sebastian-Roth I was overthinking this. I simply added it to the end of my script and set up a cron job as root. For proof of concept, I ran my script as root and it worked!

[coco65]

Hi, I am getting the same on Debian 8 Git version 7917 FOG Storage Node running inside a Virtual Box on a NAS. Copying the commands listed below as root did not make any difference in my case. Constant 100% processor load.

[Tom Elliott]

@coco65 This is highly dependent upon how you run sudo.

If you’re running where you first login as a user other than root and they sudo to root, you should run:

sudo -i <- if you’re logging in to become root.

To ensure the script being run under sudo get’s root sourcing first run the script as:
sudo bash -c 'script.sh'

[x23piracy]

@Tom-Elliott even if i try to run the script via sudo bash -c ‘script.sh’ high load still remains, that doesn’t fix it. and the problem wasnt there with older trunk versions.

[Tom Elliott]

@x23piracy The code that’s running the 100% cpu hasn’t changed.

[x23piracy]

@Tom-Elliott what should i do i cannot get away from the cpu burning. Any suggestions?
Also i cannot use systemctl like you suggested for 14.04:

root@fog-image:/home/fog# systemctl stop FOGMulticastManager
systemctl: Befehl nicht gefunden.

Ubuntu 14.04 uses Upstart as the init system, the plan to switch to systemd is planned for 14.10+. There are parts of “systemd” that have been used in Ubuntu for a long time, but for most intents and purposes when people say “systemd” they mean systemd-as-init.

And it burns for me can someone borrow a fire extinguisher? It’s hot here

Regards X23

[coco65]

@Tom-Elliott - I got tired of sudo so enabled root login. Does sudo -i make any difference then? Tried it.

[Tom Elliott]

I need solid proof if possible.

If you can find a revision where all is working properly and when it stops, I can probably be of more help.

Seeing as this seems a sporadic thing and only, to me, seems to appear on Debian based OS’s, I can guess maybe it’s got something to do with the session crontab?

Just a guess.

I haven’t made a change to the fog services that would cause this to sporadically occur.

Normally, when I do see the issue, it’s stuck in a forever loop (the services). This happens when it fails to read data from the database and get’s a 0 data.

[Wayne Workman]

@x23piracy If you have time, I can find out exactly what’s happening via TeamViewer and make a bug report afterwards.

[x23piracy]

@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

[x23piracy]

@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

[x23piracy]

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

[Tom Elliott]

@x23piracy just a guess that this goes crazy when updating.

[fry_p]

@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.