High CPU Usage on Fog Server
-
@george1421 When I followed the innodb steps on the link you sent me, I got some errors. For example, on the ALTER TABLE for tasks, I get this error “ERROR 1292 (22007): Incorrect datetime value: ‘0000-00-00 00:00:00’ for column ‘ilFinishTime’ at row 2599” These are all of the effected ones that did not change. Any suggestions on how to fix this? CPU usage still seems to be high.
-
@DJslimD1k Sorry I got pulled in another direction. On the updated versions of mariadb they made a default setting that isn’t compatible with FOG’s default one sec
Edit: You need update a mysql configuration file here: https://forums.fogproject.org/post/134207
Depending on your install version it might be in another file but in the section [mysqld] you need to add the sql-mode line then restart the database server. Once restarted then you should be able to convert the rest of the tables.
-
@george1421 So I inserted the file that you sent the link to in the /var/lib/mysql folder. I tried and followed all of the steps and I’m still getting this error when I the script to change the type.
I’m using CentOS8 and running Fog server version 1.5.9-RC2.11
-
@DJslimD1k After setting the config did you restart the MySQL/MariaDB?
-
@DJslimD1k Run the following command on the mysql server console and post the results
SELECT @@GLOBAL.sql_mode global, @@SESSION.sql_mode session;
-
@george1421 Still no luck. Here is the screenshot you requested.
-
@DJslimD1k Ok this specifically is the problem.
So your current FOG server OS is centos 8? We need to find which file the stanza of [mysqld] is located and add in
sql-mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
and then restart mysql/mariadb. When we get it right those parameters should be gone from the query.
-
@DJslimD1k First/accepted answer here: https://stackoverflow.com/questions/16603947/mysql-mode-on-linux-centos As to the location where that parameter needs to be set.
-
@DJslimD1k I have a Centos 8 fog server in my home lab and this is what I had to do.
Edit this file
/etc/my.cnf.d/mysql-server.cnf
Add this in just below the [mysqld] section header. NOTE: This is a different sql-mode values than I gave you before. Those did not seem to work on the mysqld that centos uses. I queried the values that mysqld used and then just removed the date invalid and zero switches.
sql-mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"
The config file should look like this:
[mysqld] sql-mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION" datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock log-error=/var/log/mysql/mysqld.log pid-file=/run/mysqld/mysqld.pid
Restart mysqld
systemctl restart mysqld
Then query using mysql untility to ensure that the date settings are removed as in the picture from the previous post. Once that is done you should be able to convert the remaining tables to innodb format.
-
@george1421 I had to change the permissions of that file in order for me to add the text into that file. Now when I log into fog, I get this message.
This is the result.
-
@DJslimD1k Well its because you changed the permissions on that file. You should have edited it with root user or sudo edited the file. Change the mode back to 755
sudo chmod 755 /etc/my.cnf.d/mysql-server.cnf
Then restart mysql server. -
@george1421 I believe I got it! The overall processor usage has dropped, but I still see a lot of php-fpm in the “top” view in terminal. Thank you so much for your help!
I do have the access control plugin installed on our fog server. I figured that’s what the remaining MyISAM are from.
-
@DJslimD1k the mysql value is still pretty high. Higher than I might expect. But switching from isam to innodb helps because isam uses table locking on update and innodb uses row locking. With a lot of clients polling that table locking method becomes a road block.
I didn’t look back in the tread, but didn’t your fog server have 10 vCPUs? If so I would drop those back to 4 and see where performance settles out to. Overcommiting on vCPU is worse then not providing enough vCPUs to handle the load.
Having that many php-fpm workers just means that your server is busy with requests. There is some performance tuning you can do with the php-fpm settings on a busy network by switching from dynamic to allocation to static allocation.