Joe, that’s fine. I was just surprised at the size of my userTracking table.

What tables would be useful to locate old hosts?

I don’t need fog to keep user tracking for eternity. It would be nice to be able to set a time frame of data to keep.

Another thing to keep things tidy would be to purge hosts that haven’t communicated in X amount of time.

Then maybe some schedule to run “optimize table” to get the benefits of those row removals.

Thanks for all the hard work!

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!

@Wayne-Workman
I tried changing the mpm module to worker, but PHP wasn’t happy with that.

Yes, that is where those config files are at, and the mpm_prefork is the current module in use. I didn’t know if it was the default or if it was configured as part of the fog install.

https://httpd.apache.org/docs/2.4/mpm.html
“At the user level, MPMs appear much like other Apache httpd modules. The main difference is that one and only one MPM must be loaded into the server at any time.”

Is one mpm preferred, or is there one that should be avoided for fog?

@Wayne-Workman
The changes were in place for days and reboots before being removed.

@Wayne-Workman
I’ve edited the MaxRequestWorkers in mpm_prefork.conf from 100 to 150. Unfortunately it did nothing for the performance or stability so I changed it back.

The error is on a different line now.

[Mon Feb 20 08:41:25.852210 2017] [php7:error] [pid 2063] [client 10.84.150.208:53758] PHP Fatal error: Uncaught Exception: #!ih in /var/www/html/fog/lib/client/registerclient.class.php:77\nStack trace:\n#0 /var/www/html/fog/lib/fog/fogpage.class.php(2851): RegisterClient->json()\n#1 /var/www/html/fog/lib/fog/fogpage.class.php(264): FOGPage->requestClientInfo()\n#2 /var/www/html/fog/lib/fog/processlogin.class.php(57): FOGPage->__construct(‘’)\n#3 [internal function]: ProcessLogin->__construct()\n#4 /var/www/html/fog/lib/fog/fogbase.class.php(402): ReflectionClass->newInstanceArgs(Array)\n#5 /var/www/html/fog/management/index.php(29): FOGBase::getClass(‘ProcessLogin’)\n#6 {main}\n thrown in /var/www/html/fog/lib/client/registerclient.class.php on line 77

Ah, I wasn’t aware that the storage nodes could also provide the pxe boot. That’s exactly what we’d like to do and we have a number of them, albeit running older versions.

Clients are mostly 11.5 or higher.

OS: Ubuntu 16.04
Fog:
Hardware: VM - 4 cpu @ 2.67 GHz with 12GB of ram.
Clients: 8k+

Prior - 1.30 RC 11, no problem with the same number clients and server.

My fog server is getting quite a few requests and the cpu load climbs to a point where the pxe boot will start timing out for multiple systems. Users don’t want to have to escape out of the pxe boot and I’m forced to shut the server down.

I’m wondering if it’s possible to move the ipxe services to a separate server?

I found https://wiki.fogproject.org/wiki/index.php/Separate_TFTP_and_DHCP_Server
but it’s quite dated.

@Wayne-Workman
A colleague of mine did the update to 1.3.3 and 1.3.4. The PHP version is currently at 7.1.1 on Ubuntu 14.04. I do have lines in the .fogsettings for php_ver=7.1 and php_verAdds=‘-7.1’

Please advise.

@Wayne-Workman
We probably have over 8,000 systems. I had the client checkin at 5 min and increased it to 10 min prior to posting. I appreciate the articles and I’m sure they’ll help. The memory of the server is fine and the swap is very small.

Tom, we were at 1.3 RC 11 for a while. Almost all clients should be 11.5 or higher.

@Tom-Elliott
The client login is my attempt at interpreting the apache error log.

We did briefly try 1.3.5 RC-1 with no improvement.

We have thousands of hosts.

Server

• FOG Version: 1.3.4 svn 6064
• OS: Ubuntu 14.04

Client

• Service Version: 11.x
• OS: Win 7

Description

Seeing high cpu utilization on the fog server. The server gets overwhelmed to the point of not being able to respond timely to pxe requests.

AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

The log is full of these:

PHP Fatal error: Uncaught Error: Call to a member function isValid() on null in /var/www/html/fog/lib/client/registerclient.class.php:67\nStack trace:\n#0 /var/www/html/fog/lib/fog/fogpage.class.php(2701): RegisterClient->json()\n#1 /var/www/html/fog/lib/fog/fogpage.class.php(262): FOGPage->requestClientInfo()\n#2 /var/www/html/fog/lib/fog/processlogin.class.php(57): FOGPage->__construct(‘’)\n#3 [internal function]: ProcessLogin->__construct()\n#4 /var/www/html/fog/lib/fog/fogbase.class.php(406): ReflectionClass->newInstanceArgs(Array)\n#5 /var/www/html/fog/management/index.php(29): FOGBase::getClass(‘ProcessLogin’)\n#6 {main}\n thrown in /var/www/html/fog/lib/client/registerclient.class.php on line 67

@Wayne-Workman I’ve had to rerun the delete query.

@Tom-Elliott I did run the query with the correction. Most of our groups are already built from this summer. RC11 has been very stable and responsive. I’ve reduced the client communication time from 900 to 300 with no impact to performance.

I think your team is in the “home stretch” with 1.3!

@Tom-Elliott
Should it be ‘gmHostID’ in the last line?

74 rows deleted. Membership is still behaving the same with the same error.