High CPU Usage

  • Moderator

    @Arrowtron How is this testing going? Do you see measured improvements in performance?

  • Moderator

    @Arrowtron Well, what I would like to do is make it worse to make it better. The meaning is to reset as much of the fixes you’ve done to this point to put it back to what way FOG was installed. This includes any adjustments suggested by the mysql tuner script. We need to have it as close to as installed as possible. Also reset the fog client check in time.

    Run it in the as installed configuration for a few hours during your peak business time. Use top and sort by processor usage. Grab a screen shot of the top screen.

    Shutdown apache

    Lets make sure we have a good backup of the mysql server before doing anything. From the fog server linux command prompt key in mysqldump -u root -p --all-databases > all-databases-backup.sql

    login to the mysql command line tool with mysql -u root -p fog You will need to use the password you created for the root database user when you installed fog. If you don’t know the password that could be a problem. The older version of FOG had a black password for the mysql root user. Understand I’m using mysql to mean both mysql and mariadb. The command line tool is the same.

    At db prompt paste in this command.

    FROM information_schema.TABLES

    You should see an output that looks like this

    | TABLE_NAME             | ENGINE |
    | LDAPServers            | MyISAM |
    | clientUpdates          | MyISAM |
    | dirCleaner             | MyISAM |
    | globalSettings         | MyISAM |
    | greenFog               | MyISAM |
    | groupMembers           | MyISAM |
    | groups                 | MyISAM |
    | history                | MyISAM |
    | hookEvents             | MyISAM |
    | hostAutoLogOut         | MyISAM |
    | hostMAC                | MyISAM |
    | hostScreenSettings     | MyISAM |
    | hosts                  | MyISAM |
    | imageGroupAssoc        | MyISAM |
    | imagePartitionTypes    | MyISAM |
    | imageTypes             | MyISAM |
    | images                 | MyISAM |
    | imagingLog             | MyISAM |
    | inventory              | MyISAM |
    | ipxeTable              | MyISAM |
    | keySequence            | MyISAM |
    | location               | MyISAM |
    | locationAssoc          | MyISAM |
    | moduleStatusByHost     | MyISAM |
    | modules                | MyISAM |
    | multicastSessions      | MyISAM |
    | multicastSessionsAssoc | MyISAM |
    | nfsFailures            | MyISAM |
    | nfsGroupMembers        | MyISAM |
    | nfsGroups              | MyISAM |
    | notifyEvents           | MyISAM |
    | os                     | MyISAM |
    | oui                    | MyISAM |
    | plugins                | MyISAM |
    | powerManagement        | MyISAM |
    | printerAssoc           | MyISAM |
    | printers               | MyISAM |
    | pxeMenu                | MyISAM |
    | scheduledTasks         | MyISAM |
    | schemaVersion          | MyISAM |
    | snapinAssoc            | MyISAM |
    | snapinGroupAssoc       | MyISAM |
    | snapinJobs             | MyISAM |
    | snapinTasks            | MyISAM |
    | snapins                | MyISAM |
    | supportedOS            | MyISAM |
    | taskLog                | MyISAM |
    | taskStates             | MyISAM |
    | taskTypes              | MyISAM |
    | tasks                  | MyISAM |
    | userCleanup            | MyISAM |
    | userTracking           | MyISAM |
    | users                  | MyISAM |
    | virus                  | MyISAM |
    | wolbroadcast           | MyISAM |
    55 rows in set (0.00 sec)

    If your tables show innodb then we have to stop because your database is not in the default state.

    If your database files say MyISAM then proceed and paste in these lines. You can do them in one block paste in. Just make sure the last line is entered too.

    ALTER TABLE clientUpdates ENGINE=InnoDB;
    ALTER TABLE dirCleaner ENGINE=InnoDB;
    ALTER TABLE globalSettings ENGINE=InnoDB;
    ALTER TABLE groupMembers ENGINE=InnoDB;
    ALTER TABLE history ENGINE=InnoDB;
    ALTER TABLE hookEvents ENGINE=InnoDB;
    ALTER TABLE hostAutoLogOut ENGINE=InnoDB;
    ALTER TABLE hostScreenSettings ENGINE=InnoDB;
    ALTER TABLE imageGroupAssoc ENGINE=InnoDB;
    ALTER TABLE imagePartitionTypes ENGINE=InnoDB;
    ALTER TABLE imageTypes ENGINE=InnoDB;
    ALTER TABLE imagingLog ENGINE=InnoDB;
    ALTER TABLE inventory ENGINE=InnoDB;
    ALTER TABLE ipxeTable ENGINE=InnoDB;
    ALTER TABLE keySequence ENGINE=InnoDB;
    ALTER TABLE location ENGINE=InnoDB;
    ALTER TABLE locationAssoc ENGINE=InnoDB;
    ALTER TABLE moduleStatusByHost ENGINE=InnoDB;
    ALTER TABLE modules ENGINE=InnoDB;
    ALTER TABLE multicastSessions ENGINE=InnoDB;
    ALTER TABLE multicastSessionsAssoc ENGINE=InnoDB;
    ALTER TABLE nfsFailures ENGINE=InnoDB;
    ALTER TABLE nfsGroupMembers ENGINE=InnoDB;
    ALTER TABLE nfsGroups ENGINE=InnoDB;
    ALTER TABLE notifyEvents ENGINE=InnoDB;
    ALTER TABLE plugins ENGINE=InnoDB;
    ALTER TABLE powerManagement ENGINE=InnoDB;
    ALTER TABLE printerAssoc ENGINE=InnoDB;
    ALTER TABLE printers ENGINE=InnoDB;
    ALTER TABLE scheduledTasks ENGINE=InnoDB;
    ALTER TABLE schemaVersion ENGINE=InnoDB;
    ALTER TABLE snapinAssoc ENGINE=InnoDB;
    ALTER TABLE snapinGroupAssoc ENGINE=InnoDB;
    ALTER TABLE snapinJobs ENGINE=InnoDB;
    ALTER TABLE snapinTasks ENGINE=InnoDB;
    ALTER TABLE snapins ENGINE=InnoDB;
    ALTER TABLE supportedOS ENGINE=InnoDB;
    ALTER TABLE taskStates ENGINE=InnoDB;
    ALTER TABLE taskTypes ENGINE=InnoDB;
    ALTER TABLE userCleanup ENGINE=InnoDB;
    ALTER TABLE userTracking ENGINE=InnoDB;
    ALTER TABLE wolbroadcast ENGINE=InnoDB;

    Once that is done run the same query again to make sure all of the tables now say innodb

    FROM information_schema.TABLES

    If they are all innodb then you can exit the mysql program if I missed one then run the ALTER TABLE command on those missing tables. Please not any table I missed.

    At this point reboot the FOG server.

    When the fog server comes back up make sure the web ui works as expected. Let the FOG server run for a few hours then again capture a snapshot for the settings using top. Post the results here.

    This next test is to let the FOG server run for a week using the innodb format then rerun the mysql tuner script. DON’T apply the settings, but post the results here. Let us look at the recommendations before you apply them to the FOG server’s database.

    In the end what we need to know is the change in performance by simply changing the database engine from isam to innodb format. Also to see the recommendations provided by mysqltuner. I have some default settings for the innodb that I would start out with, but they may not be right for all situation.

    Let me say we do need help from FOG Admins who have either unique target hardware or large installations that can’t be simulated easily. With your help I feel strongly that we can improve FOG’s performance and move everyone’s FOG install in a positive direction.

  • @george1421 said in High CPU Usage:

    @Arrowtron I have some ideas of what we can do here if you are willing to help the FOG Project team.

    Yes can do, let me know what information you need

  • Moderator

    @Arrowtron I have some ideas of what we can do here if you are willing to help the FOG Project team.

  • @Sebastian-Roth
    Thanks for your reply, I have changed the client checkin time from 60 to 600 (10mins) and has made a huge difference (picture below)

    Client Maxsize: 204800000
    Grace Timeout: 60


  • Moderator

    This post is deleted!

  • Moderator

    @george1421 Relevant github issue for further discussion and thoughts on MyISAM -> InnoDB specifically: https://github.com/FOGProject/fogproject/issues/370

  • Moderator

    @Sebastian-Roth The more I look into this the more I’m going to blame mysql and the ISAM table format for the OP’s issue. ISAM uses table locking for updates to the data, where INNODB uses row level locking for updates. SO if you have 10 systems updating the fog history table that is in ISAM format, one system will have update access while 9 will be placed in a blocked status until the first system finishes its update action. When the first finishes, then the second in line will get its chance and so on. I think with FOG 1.6.x stream we should setup the innodb as the default table engine. Understand we NEED to do a lot more bench marking on this issue, but I think with the help of the OP and other large FOG deployments we can get a better understanding of what it will take to make FOG go faster…

  • Moderator

    Some of the testing a few of the big fog installs have done show that switching mysql over from isam to innodb format help with a heavily loaded mysql instance

    If you have the ram, with 400 clients on at one time you might want to take your pm.max_children to 50 from 35. For larger installs (500 fog clients and up) some have switched over php-fpm from dynamic clients to static clients so there isn’t the stand up time for new php-fpm children if the server gets hit hard with requests.

    Look at the fog client check in time. If its default, its probably 5 minutes. Increase that to 10 or 15 minutes. Understand that increase will slow the the time between issuing a snapin deployment and the client seeing the request. It will have no impact on imaging.

  • Developer

    @Arrowtron Overall from what you wrote I would imagine this is happening due to the clients checking in “too often” in your setup. See there are many variables that influence this, some you can alter very easily but others that are just hard facts (like your network speed and load - the longer one request takes the more need to be handled in parallel).

    Restarting the server, CPU usage isn’t as bad, eventually goes to 100% the longer it is on

    Sure client connections are all dropped and come back over time.

    Took a snapshot, upgraded to the latest dev-branch a couple weeks back (i think ~, CPU usage was still hovering quite high, reverted back

    Hmm? FOG is only available since yesterday. You probably were using a different version then.

    Ran MySQLTuner, results below

    Sorry, I am not an expert on this. Others might give you hints on this. @george1421 @EduardoTSeoane Sure thing, FOG does not do a great job in optimizing the DB backend as of now. This is something we need to pay more attention to in the future.

    Ran Database Maintenance Commands on https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL

    Good thing to do although it didn’t help.

    I haven’t changed any polling/refresh rates for hosts, I’ve seen on these forums that has helped for others

    This is the first thing I’d suggest you do to actually find out if it’s the clients causing the load. At least double the checkin time (FOG web UI settings) and wait for half an hour so every client has pulled and adjusted to the new setting.

    https://forums.fogproject.org/topic/12392/fog-server-high-cpu/23?_=1582602629372 - I’ve tinkered with the settings below but no drop in CPU

    That might be a hint on this being the database backend causing it and not the webserver. Though we will see.

Log in to reply