1.3.4 - high cpu load - client login

[UWPVIOLATOR]

Good News! CPU load was low all day today. Mid day we turned the FOG Service back on at a few sites. We will monitor this tomorrow morning then add more clients back and report back.

What we did.

Disabled IMAGEREPLICATORGLOBALENABLED
Increased MaxRequestWorkers from 150 to 500 in mpm_prefork_module
Reset all host encryption UPDATE hosts SET hostPubKey= ‘’, hostSecToken = ‘’;

[Tom Elliott]

Do you guys think it’s suitable to solve this yet, or just hold for a little bit?

Would you guys mind jumping on the working branch to see if the changes there will help fix the issue more directly? I believe the high load was coming from the constant md5summing that was happening for each image every cycle the replicator service was running.

I’ve switched out to using the first and last 10 mb of the files at both the remote and local systems, hash those together (Thanks @Wayne-Workman and @Junkhacker) and compare. So it’s still entirely possible that load can still get high (if it has to replicate multiple images/snapins at the same time) but it should be less CPU intensive during the “checking” processes.

[ablohowiak]

We had <25% of clients enabled this morning. We need to clean up the snapshots on the server before we can update. It might be this afternoon or Monday.

We’re still going to re-enable clients in steps just to be safe. By Tuesday morning all clients should be running again.

Thanks again for all your time and effort!

[UWPVIOLATOR]

@Tom-Elliott

One thing we notice that is still not working is WOL to Groups. WOL works for individual hosts but not for WOL to a Group. Also Report Management does not return anything for any of the reports.

[Florent]

@Tom-Elliott said in 1.3.4 - high cpu load - client login:

11

Hi,
We have the same problem.
Is this problem is resolved in RC10 ?
Or when RC11 available ?

Regards.

[Tom Elliott]

@Florent What is:

“We have the same problem.”?

I ask because there seems to be multiple issues being described in this thread, while the primary issue was related to High CPU. Are you referring to High CPU usage being an issue?

[Florent]

@Tom-Elliott
Thanks for your response (my english is not very good).

Yes we have high CPU usage since we have deploy the new client (0.11.9) with GPO.

We have try to modify FOG_CLIENT_CHECKIN_TIME but we think value over 60 seconds are no effects.
In our client log we see in general a contact server every 60-200 seconds.
We have more than 1500 clients.

If the problem is here is it possible to modify checkin time to 15 minutes ?

Or if the problem is not this where i can find informations for identify in detail the source of the problem ?

Regards

[UWPVIOLATOR]

@Florent

Do you see something like this in your processes on your FOG server?

We Disabled IMAGEREPLICATORGLOBALENABLED until Tom fixes the image checking in the next RC.

[Florent]

@UWPVIOLATOR
Just do this on Web interface / fog settings or after restart apache ?

[Tom Elliott]

@Florent In the GUI.

FOG Configuration Page->FOG Settings->FOG Linux Service Enabled

[ablohowiak]

Tom,
We added back about 75% of our clients and the load has remained stable and UI responsive. I was trying to update to 1.3.5-RC10, but the install failed.

• Downloading inits, kernels, and the fog client…Failed!

Feb 28 12:47:24 FogDB systemd[1]: Starting MySQL Community Server…
Feb 28 12:47:26 FogDB systemd[1]: Started MySQL Community Server.
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: YES)
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: YES)

At this point there’s basically no fog site in apache. I’m reverting back to my last snapshot.

[Florent]

@Tom-Elliott Yes imagereplicatorglobalenabled is not checked

[Florent]

@UWPVIOLATOR said in 1.3.4 - high cpu load - client login:

Increased MaxRequestWorkers from 150 to 500 in mpm_prefork_module
Hi,
Where you have put this parameter because i try in my apache2.conf in prefork module but not valid after i restart apache2

[ablohowiak]

So no improvement with imagereplicatorglobalenabled off?

With this issue I’ve increase my client communication up to 30 minutes. I will reduce when I know things have stabilized.

In Ubuntu, see which mpm you have enabled. There should only be one in /etc/apache2/mods-enabled. That’s the file you would edit to increase the MaxRequestWorkers. Make a copy of the file before editing.

[Florent]

@ablohowiak said in 1.3.4 - high cpu load - client login:

So no improvement with imagereplicatorglobalenabled off?

No

With this issue I’ve increase my client communication up to 30 minutes. >I will reduce when I know things have stabilized.

Where you have up to 30 minutes your client communication , “checkin time parameter” ?

[ablohowiak]

Yes.

[Florent]

@ablohowiak
Oh very thanks it’s works !
I was thinking test this before but maybe not with “imagereplicatorfogenabled” at off.
After few minutes cpu is ok.

Thanks.

[Florent]

@ablohowiak @Tom-Elliott

Hi,

Today it’s better but all the 30 minutes we have pic of 2 minutes.

In wiki it’s write (https://wiki.fogproject.org/wiki/index.php?title=FOG_Client

The frequency of the checkin-time determines how quickly the FOG Client will receive instructions from the FOG Server. If an image deployment is scheduled for a computer that is turned on, with a checkin-time of 60 seconds, means the FOG Client may begin initiating the task anywhere from 0 to 60 seconds + the random staggering time that is added. This same concept would apply to immediate power management tasks, snapin tasks, capture tasks, and so on. Scheduled tasks are not affected by this behavior, and if the target system is on when the scheduled task is to be ran, this will happen on time

How it’s possible to modify the random staggering range for spread over 10 minutes for example ?

Thanks.

[Wayne Workman]

@Florent said in 1.3.4 - high cpu load - client login:

How it’s possible to modify the random staggering range for spread over 10 minutes for example ?

The staggering is not meant to be adjustable, what’s meant to be adjustable is the FOG_CLIENT_CHECKIN_TIME, this governs how often the FOG Client should check with the server. Assuming 10,000 computers power on all at exactly the same moment, over the course of the day the random staggering will cause all clients to spread out evenly with their check-ins. But nobody has 10,000 systems all powering on at the same second. Generally, organizations either A. leave their computers on all the time or B. allow the end-users to power them on.

Also asking @Joe-Schmitt if he could give further explanation.

[ablohowiak]

1.3.5-RC 10 and working fine.

All clients are back on, I’ve already reduced the client check in time, and the load was fine for the start of the school day.

The Image replicator service is still off.