SOLVED New to MySQL optimization - need help!

Tim Yearman

Jan 21, 2020
cPanel Access Level
Root Administrator
Hi there,

Forgive my for my ignorance in all of this.

My company has just migrated our PHP web application to a new Centos 7 server with 8 CPUs and 32GB of RAM. (Our old server was Centos 6 had 4 CPUs and 6MB RAM)
We were previously running MySQL 5.6 on our old server and this new server runs 5.7.

I did not configure the old server, I "inherited it" so to speak and I have very little knowledge in how this all works.

My issue is, pages in our custom web application that used to take 2 seconds to load are now taking upwards of 30 seconds and I now have to explain to my manager why as well as come up with a solution.

Using WHM's "Process Manager" I see that MySQL is using:
220% of CPU
0.5% of memory
Command = /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/

Here is the contents of the my.cnf file
The only change I made was adding sql_mode="" to the end. I did this not because I know what I'm doing, rather it was a suggested solution to an error I was getting.
(I assume due to changing from 5.6 to 5.7?)

# For advice on how to change settings please see

# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M

# Disabling symbolic-links is recommended to prevent assorted security risks

Yesterday I learned about and here is the output based on the admittedly short time that MySQL has been running:

 >>  MySQLTuner 1.7.19 - Major Hayden <[email protected]>
 >>  Bug reports, feature requests, and downloads at
 >>  Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
Please enter your MySQL administrative login: dashboar_user
Please enter your MySQL administrative password: [!!] failed to execute: SHOW SLAVE STATUS\G
[!!] FAIL Execute SQL / return code: 256
[!!] failed to execute: SHOW SLAVE HOSTS
[!!] FAIL Execute SQL / return code: 256
[OK] Currently running supported MySQL version 5.7.29
[OK] Operating on 64-bit architecture
-------- Log file Recommendations ------------------------------------------------------------------
[OK] Log file /var/log/mysqld.log exists
[--] Log file: /var/log/mysqld.log(10K)
[OK] Log file /var/log/mysqld.log is readable.
[OK] Log file /var/log/mysqld.log is not empty
[OK] Log file /var/log/mysqld.log is smaller than 32 Mb
[!!] /var/log/mysqld.log contains 3 warning(s).
[!!] /var/log/mysqld.log contains 20 error(s).
[--] 1 start(s) detected in /var/log/mysqld.log
[--] 1) 2020-01-20T19:16:31.176485Z 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 1 shutdown(s) detected in /var/log/mysqld.log
[--] 1) 2020-01-20T12:42:19.356005Z 0 [Note] /usr/sbin/mysqld: Shutdown complete
-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Data in MyISAM tables: 2.2G (Tables: 114)
[--] Data in InnoDB tables: 2.1G (Tables: 85)
[OK] Total fragmented tables: 0
-------- Analysis Performance Metrics --------------------------------------------------------------
[--] innodb_stats_on_metadata: OFF
[OK] No stat updates during querying INFORMATION_SCHEMA.
-------- Security Recommendations ------------------------------------------------------------------
[!!] failed to execute: SELECT CONCAT(user, '@', host) FROM mysql.user WHERE TRIM(USER) = '' OR USER IS NULL
[!!] FAIL Execute SQL / return code: 256
[OK] There are no anonymous accounts for any database users
[!!] failed to execute: SELECT CONCAT(user, '@', host) FROM mysql.user WHERE (authentication_string = '' OR authentication_string IS NULL) AND plugin NOT IN ('unix_socket', 'win_socket', 'auth_pam_compat')
[!!] FAIL Execute SQL / return code: 256
[OK] All database users have passwords assigned
[!!] failed to execute: SELECT CONCAT(user, '@', host) FROM mysql.user WHERE CAST(authentication_string as Binary) = PASSWORD(user) OR CAST(authentication_string as Binary) = PASSWORD(UPPER(user)) OR CAST(authentication_string as Binary) = PASSWORD(CONCAT(UPPER(LEFT(User, 1)), SUBSTRING(User, 2, LENGTH(User))))
[!!] FAIL Execute SQL / return code: 256
[!!] failed to execute: SELECT CONCAT(user, '@', host) FROM mysql.user WHERE HOST='%'
[!!] FAIL Execute SQL / return code: 256
[!!] There is no basic password file list!
-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined
-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 16h 48m 17s (560K q [9.259 qps], 17K conn, TX: 4G, RX: 164M)
[--] Reads / Writes: 85% / 15%
[--] Binary logging is disabled
[--] Physical Memory     : 31.3G
[--] Max MySQL memory    : 38.1G
[--] Other process memory: 0B
[--] Total buffers: 169.0M global + 257.1M per thread (151 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 2.9G (9.36% of installed RAM)
[!!] Maximum possible memory usage: 38.1G (121.81% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory
[OK] Slow queries: 0% (0/560K)
[OK] Highest usage of available connections: 7% (11/151)
[OK] Aborted connections: 0.10%  (18/17871)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[!!] Query cache may be disabled by default due to mutex contention.
[!!] Query cache efficiency: 0.0% (0 cached / 438K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (50 temp sorts / 261K sorts)
[!!] Joins performed without indexes: 38078
[OK] Temporary tables created on disk: 18% (3K on disk / 17K total)
[OK] Thread cache hit rate: 99% (13 created / 17K connections)
[!!] Table cache hit rate: 10% (2K open / 19K opened)
[OK] table_definition_cache(1400) is upper than number of tables(260)
[OK] Open file limit used: 12% (1K/10K)
[OK] Table locks acquired immediately: 99% (208K immediate / 208K locks)
-------- Performance schema ------------------------------------------------------------------------
[--] Performance schema is disabled.
[--] Memory used by P_S: 0B
[--] Sys schema isn't installed.
-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is disabled.
-------- MyISAM Metrics ----------------------------------------------------------------------------
[OK] Key buffer used: 100.0% (8M used / 8M cache)
[OK] Key buffer size / total MyISAM indexes: 8.0M/180.7M
[OK] Read Key buffer hit rate: 99.6% (3M cached / 14K reads)
[!!] Write Key buffer hit rate: 62.6% (182K cached / 114K writes)
-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[!!] InnoDB buffer pool / data size: 128.0M/2.1G
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M should be equal to 25%
[OK] InnoDB buffer pool instances: 1
[--] Number of InnoDB Buffer Pool Chunk : 1 for 1 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 99.58% (7206918690 hits/ 7237168717 total)
[!!] InnoDB Write Log efficiency: 80.71% (17870 hits/ 22140 total)
[OK] InnoDB log waits: 0.00% (0 waits / 40010 writes)
-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is disabled.
-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.
-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.
-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.
-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: ROW
[--] XA support enabled: ON
[--] Semi synchronous replication Master: Not Activated
[--] Semi synchronous replication Slave: Not Activated
[--] This is a standalone server
-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    Control warning line(s) into /var/log/mysqld.log file
    Control error line(s) into /var/log/mysqld.log file
    MySQL was started within the last 24 hours - recommendations may be inaccurate
    Reduce your overall MySQL memory footprint for system stability
    Dedicate this server to your database for highest performance.
    Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
    We will suggest raising the 'join_buffer_size' until JOINs not using indexes are found.
             (specially the conclusions at the bottom of the page).
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64:
    Read this before increasing for MariaDB
    This is MyISAM only table_cache scalability problem, InnoDB not affected.
    See more details here:
    This bug already fixed in MySQL 5.7.9 and newer MySQL versions.
    Beware that open_files_limit (10000) variable
    should be greater than table_open_cache (2000)
    Performance schema should be activated for better diagnostics
    Consider installing Sys schema from for MySQL
    Consider installing Sys schema from for MariaDB
    Before changing innodb_log_file_size and/or innodb_log_files_in_group read this:
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (=0)
    query_cache_type (=0)
    query_cache_limit (> 1M, or use smaller result sets)
    join_buffer_size (> 256.0K, or always use indexes with JOINs)
    table_open_cache (> 2000)
    performance_schema = ON enable PFS
    innodb_buffer_pool_size (>= 2.1G) if possible.
    innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
I am completely lost in all of this and any suggestions would be greatly appreciated!


Product Owner II
Staff member
Nov 14, 2017
Do you have the my.cnf that was present on the old server? Have you followed any of the advice provided to you by the tuner? Ultimately, this isn't something that is best suited for this forum and you should look at getting a database expert to handle this. If you don't have someone, you might try looking here: System Administration Services


Well-Known Member
Jan 18, 2003
Jacksonville, FL
cPanel Access Level
DataCenter Provider
I cannot say for sure without checking your system, but you may have some SQL mode issues. I've seen cases where upgrades to MySQL 5.7 have caused some SQL queries to have issues. This is do a a change in the sql_mode. You may want to try this mode:

I cannot guarantee that this will help without investigating but it negates some of the changes introduced into MySQL 5.7.

You would need to track which queries are slow using your slow logs and then run explain on them.

Also, check your logs for broken indexes of if you have a small database, just run an optimize/repair on all of the tables.

Make sure you have backups.

Tim Yearman

Jan 21, 2020
cPanel Access Level
Root Administrator
"Also, check your logs for broken indexes of if you have a small database, just run an optimize/repair on all of the tables."

So, as I stated before, I kind of "inherited" this application and didn't know all of the "ins and outs".
Apparently, MySQL on our old server was configured in such a way as to minimize the impact on poorly written code, and most importantly, very poorly optimized tables.

I've gone ahead and added indexes where (without deep diving into the code) they were obviously lacking.

Immediate improvement

Thank you for pointing me in the right direction!

Not sure how to mark this thread as solved or closed, but I would consider my issue resolved.

  • Like
Reactions: cPanelLauren