Web GUI error after clicking List Hosts
-
@george1421 Okay I did the commands, some did error out saying they dont exist but this are the results of the final command. Website seems to be running smoother. Will continue to monitor.
+------------------------+--------+ | TABLE_NAME | ENGINE | +------------------------+--------+ | clientUpdates | InnoDB | | dirCleaner | InnoDB | | fileChecksums | MyISAM | | globalSettings | InnoDB | | greenFog | InnoDB | | groupMembers | InnoDB | | groups | InnoDB | | history | InnoDB | | hookEvents | InnoDB | | hostAutoLogOut | InnoDB | | hostMAC | InnoDB | | hostScreenSettings | InnoDB | | hosts | InnoDB | | hoststatus | MyISAM | | imageGroupAssoc | InnoDB | | imagePartitionTypes | InnoDB | | imageTypes | InnoDB | | images | InnoDB | | imagingLog | InnoDB | | inventory | InnoDB | | ipxeTable | InnoDB | | keySequence | InnoDB | | location | InnoDB | | locationAssoc | InnoDB | | moduleStatusByHost | InnoDB | | modules | InnoDB | | multicastSessions | InnoDB | | multicastSessionsAssoc | InnoDB | | nfsFailures | InnoDB | | nfsGroupMembers | InnoDB | | nfsGroups | InnoDB | | notifyEvents | InnoDB | | os | InnoDB | | oui | InnoDB | | plugins | InnoDB | | powerManagement | InnoDB | | printerAssoc | InnoDB | | printers | InnoDB | | pxeMenu | InnoDB | | scheduledTasks | InnoDB | | schemaVersion | InnoDB | | snapinAssoc | InnoDB | | snapinGroupAssoc | InnoDB | | snapinJobs | InnoDB | | snapinTasks | InnoDB | | snapins | InnoDB | | supportedOS | InnoDB | | taskLog | InnoDB | | taskStates | InnoDB | | taskTypes | InnoDB | | tasks | InnoDB | | userCleanup | InnoDB | | userTracking | InnoDB | | users | InnoDB | | virus | InnoDB | +------------------------+--------+ 55 rows in set (0.00 sec)
-
@tesparza OK I see two tables either I missed or there was an error converting.
Can you run these commands
use fog ALTER TABLE fileChecksums ENGINE=InnoDB; ALTER TABLE hoststatus ENGINE=InnoDB;
You can do this now or later. You got the big tables that cause resource contention already, these are just for completeness.
I’m glad the innodb switch has settled down your FOG server, lets see how it runs for the next day or so to see if we need to tune it a bit more.
-
@george1421 Okay now everything is InnoDB, Server is running bad, web gui taking long time to load, can’t image. CPU usage is around 40%
FYI this is running of a Optiplex 7010 i5 quad core, 8gb ram
Do I maybe need to switch to a server?
-
@tesparza Ok the innodb engine is much more efficient than myisam, so the effort is not wasted. It will never be worse with innodb format.
So what is your top process now? Post a screen shot of top sorted by
P
rocess.How many computers with FOG clients?
What is your client check in interval? Still the default of 5 seconds?Don’t change anything lets see where we are at first.
-
-
@tesparza For testing lets change the check in interval to 300 seconds (5 minutes) and then lets wait 15 minutes to see if things settle down. This isn’t the answer at the moment, its just to see if having 2000 hosts hit (if we lineralize it, 34 per second) is a bit too much for your hardware.
The screen shot you shown is indicative of what a myisam engine configuration will give us. We know we already fixed that.
Looking at top, it also appears you only have 4GB of ram. Can you do a
uname -a
and post the results here? -
@george1421 Okay interval changed to 300
-
@tesparza well that’s a good thing you have a 64 bit OS. Since you are telling me 8GB is installed but top is reporting only 4GB then I was thinking a 32 bit OS.
If the 300 second check in doesn’t settle things down, then please confirm you have 8GB installed. Since is a 7010 you might be able to find some old memory to top it out at 16GB. I know I have at least 10 sticks of 4GB 7010 memory in the bottom of my junk bin. I’m hoping you have similar.
Again when things settle down a bit we’ll check also disk performance. Right now the sql sever is having a high cpu load. This could be either disk, or not enough free ram for caching to happen. We need to make small changes to see where things pick up the most.
-
@george1421 Okay it seems to be running smoother, I will add more RAM, eventually I will transfer to a server.
-
@tesparza I made a post a few years ago to test different hardware and its impact on imaging speed. We may need to reference it as we work through this.
https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast
If your fog server has a sata spinning hard drive that may also be the culprit. But again testing will show us.
-
@george1421 Okay I have upgraded the RAM to 16gb. Will see how it goes. Thank you.
-
@tesparza Did you have 4GB in there when you opened the machine? Does top now show 16GB of ram? I’m kind of interested in why things were reporting as they were.
-
Running smooth so far. Yes it had 4GB before.
-
@tesparza Its good we can point our finger at low memory as the problem. The small cache space on 4GB is only left 800MB of room so mysql had to commit everything to disk instead of caching it for later. (speculation) I did find it surprising that in the previous top screen shot, you had 4GB of swap space but none was used even when the system was low on ram. It wouldn’t have really helped in your case, but I find it strange that no swap space was used.
Now that you found an acceptable level you can start decreasing your fog client check in time till you find a happy balance between speed and frequency. The only issue I can think of by keeping the check in time to 5 minutes would be during post imaging if the fog client was used to rename the system, connect to AD, or do a scheduled reboot. Its possible the client computer wouldn’t react to the command for about 5 minutes.
-
This post is deleted!