How to configure mysql to prevent processor spikes

I’m running a WordPress site using the one-click DigitalOcean droplet with 2 vCore, 4GB of RAM, 80GB SSD, Ubuntu 18.04, Apache 2.4.29, and mysql community server version 8.0.20.

For a few days, the site was working fine, but then after trying to run a table optimization on the database, the CPU is all over the place going from 1% to 100% down to 1% and 100%, even after restarting the server, the high CPU usage is constant, and it’s one mysql process taking most of processor time.

I’m using htop to monitor the resources.

In mysql, I use the “Show processlist” command everything looks normal, and no query is hanging. If I redo the command, I may see some WordPress related queries, but redoing the command again, the queries complete successfully. However, CPU keeps going up and down, sometimes staying 100% for 10 to 20 seconds and more.

This is causing the site to be super slow and queries (without caching), for example, to render the homepage takes around 7 seconds and saving posts take a long time too.

I tried disabling all the plugins and theme, but the CPU continues to spike up and down.

While the plugins and theme were disabled, I activated the “Optimize Database after Deleting Revisions” which I used for years. Trying to delete 46 pingback links 17 minutes (it completed successfully though).

The thing is that I used to have the site on another droplet using Ubuntu 16.04 with the same hardware specifications and older version of mysql and apache, and the CPU was always below 10%, so there was no high CPU usage.

I’ve researching and troubleshooting this problem for a while, I thought the high CPU usage was because of the database, but I’m now thinking in the mysql configuration.

Upon checking, inside /etc/mysql folder, I see two folders and four files, including conf.d and mysql.conf.d folders and Debian.cnf, my.cnf.fallback, mysql.cnf files, and there’s a my.conf file but it’s a symlink pointing to /etc/alternatives/my.cnf which then points to /etc/mysql/mysql.cnf.

This is what’s inside the mysql.cnf:

# The MySQL  Server configuration file.
# For explanations see

# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

This is what’s inside the conf.d/mysql.cnf file:

# The MySQL  Client configuration file.
# For explanations see


Then inside the mysql.conf.d the only thing I see a mysqld.cnf file with this content:

# The MySQL  Server configuration file.
# For explanations see

pid-file	= /var/run/mysqld/
socket		= /var/run/mysqld/mysqld.sock
datadir		= /var/lib/mysql
log-error	= /var/log/mysql/error.log

============ Belwo: OLD server information for reference

I was looking an OLD backup of the droplet using Ubuntu 16.04, and the mysqld.cnf looked like this:

# The MySQL database server configuration file.
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
# For explanations see

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

socket		= /var/run/mysqld/mysqld.sock
nice		= 0

# * Basic Settings
user		= mysql
pid-file	= /var/run/mysqld/
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
lc-messages-dir	= /usr/share/mysql
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address		=
# * Fine Tuning
key_buffer_size		= 16M
max_allowed_packet	= 16M
thread_stack		= 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover-options  = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
# * Query Cache Configuration
query_cache_limit	= 1M
query_cache_size        = 16M
# * Logging and Replication
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
# Error log - should be very few entries.
log_error = /var/log/mysql/error.log
# Here you can see queries with especially long duration
#log_slow_queries	= /var/log/mysql/mysql-slow.log
#long_query_time = 2
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id		= 1
#log_bin			= /var/log/mysql/mysql-bin.log
expire_logs_days	= 10
max_binlog_size   = 100M
#binlog_do_db		= include_database_name
#binlog_ignore_db	= include_database_name
# * InnoDB
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# * Security Features
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

Could the lack of configuration in the mysqld.cnf file be the reason of the high cpu usage?

Any other place I could check for configurations? (in this server there’s not a /etc/my.cnf.)

Could I use the mysqld.cnf from the old server running an older version of mysql in the new droplet running Ubuntu 18.04?

Can anyone suggest an solution to fix the high CPU usage with mysql?

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

I’ll check your suggestions. However, this is what do get: why when setting up the droplet, everything about WordPress, themes, plugins, and everything worked OK. Then when I try to optimize the database manually or with a plugin, it’ll finish successfully (after 20 mins, when it used to take 1 to 2 mins), then the CPU usage goes crazy?


Hi there @mhweb,

What I could suggest in your case is:

  • Try using the MySQL tuner script, it will give you some suggestions on how to tweak your MySQL configuration, you can take a look at this answer here on how to do that:

  • As you mentioned, adding a caching plugin as WP Super cache could drastically reduce the overall load on the server as it would cache your pages so that your site does not have to make so many SQL connections on every page visit

  • I could also suggest checking your Apache access log for some suspicious requests which could be bringing your CPU load up, you could, for example, use this script here to quickly summarize your access log

You’ve already mentioned this, but I would as well recommend keeping your plugin count to as low as possible.

Let me know how it goes! Regards, Bobby