Error Establishing a database connection issues

Posted June 16, 2017 3.9k views
ApacheUbuntu 16.04

I’m relatively new to using digital ocean and VPS hosting in general. I recently used the “how to debug Wordpress” tutorial and based on the results, I’m running out of memory.

I don’t see how that’s possible. It’s a single page website with no traffic. The server has 1g of memory and 30gb of disk space. Furthermore, I have multiple websites running on the 5$ version of DigitalOcean that don’t run into this issue even though they have many pages and receive some traffic.

Is there any way for me to see what’s eating up all my memory?

Also, I followed the instruction on how to turn off XML-RPC so that won’t be the cause.

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.

Submit an Answer
7 answers

Hi @semipro

Try installing htop which gives you detailed information about all processes real-time:

sudo apt install htop

Is the site on the $10 using the same theme and plugins as the $5 sites? A single heavy or badly coded theme/plugin can even make a $80 droplet go to a crawl.

  • I’m using a premium theme. It’s one of the most widely used premium themes for wordpress. I only have a few plugins and they are all popular and widely used such as Yoast.

    I’m looking at htop now and it doesn’t seem like I’m anywhere near maxing out on my memory. The highest I’ve seen memory usage go is 500m.

    The only real difference between this site and the others is I’m using cloudflare and https.

    Also, since my first post I’ve run a repair on the database which had no effect.

    • @semipro
      So you’re currently at 500MB RAM usage with everything running?
      Are you using Let’s Encrypt or just the CloudFlare HTTPS?
      You can post the last 40 lines of the MySQL error log, which should help us:

      tail -40 /var/log/mysql/error.log
      • Yes, it seems to sit slightly under 500M on average.

        I’m just using cloudflare and their free SSL.

        For some reason I can’t submit the post with the full results of the command

        • 2017-06-16T23:51:57.714406Z 0 [Note] Shutting down plugin ‘binlog’
          2017-06-16T23:51:57.715326Z 0 [Note] /usr/sbin/mysqld: Shutdown complete

          2017-06-16T23:52:15.703712Z 0 [Warning] Changed limits: maxopenfiles: 1024 (requested 5000)
          2017-06-16T23:52:15.703802Z 0 [Warning] Changed limits: tableopencache: 431 (requested 2000)
          2017-06-16T23:52:15.917384Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use –explicitdefaultsfortimestamp server option (see documentation for more details).
          2017-06-16T23:52:15.920400Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.18-0ubuntu0.16.04.1) starting as process 15437 …
          2017-06-16T23:52:15.928930Z 0 [Note] InnoDB: PUNCH HOLE support available
          2017-06-16T23:52:15.929031Z 0 [Note] InnoDB: Mutexes and rw
          locks use GCC atomic builtins
          2017-06-16T23:52:15.929041Z 0 [Note] InnoDB: Uses event mutexes
          2017-06-16T23:52:15.929049Z 0 [Note] InnoDB: GCC builtin _atomicthread_fence() is used for memory barrier
          2017-06-16T23:52:15.929060Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
          2017-06-16T23:52:15.929073Z 0 [Note] InnoDB: Using Linux native AIO
          2017-06-16T23:52:15.929771Z 0 [Note] InnoDB: Number of pools: 1
          2017-06-16T23:52:15.930044Z 0 [Note] InnoDB: Using CPU crc32 instructions
          2017-06-16T23:52:15.933879Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
          2017-06-16T23:52:15.949695Z 0 [Note] InnoDB: Completed initialization of buffer pool

          • 2017-06-16T23:52:15.954142Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
            2017-06-16T23:52:15.971243Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
            2017-06-16T23:52:16.000591Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
            2017-06-16T23:52:16.000712Z 0 [Note] InnoDB: Setting file ’./ibtmp1’ size to 12 MB. Physically writing the file full; Please wait …
            2017-06-16T23:52:16.047715Z 0 [Note] InnoDB: File ’./ibtmp1’ size is now 12 MB.
            2017-06-16T23:52:16.048794Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
            2017-06-16T23:52:16.048815Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
            2017-06-16T23:52:16.050974Z 0 [Note] InnoDB: Waiting for purge to start
            2017-06-16T23:52:16.101364Z 0 [Note] InnoDB: 5.7.18 started; log sequence number 91615013
            2017-06-16T23:52:16.105239Z 0 [Note] Plugin ‘FEDERATED’ is disabled.
            2017-06-16T23:52:16.107033Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ibbufferpool
            2017-06-16T23:52:16.120995Z 0 [Note] InnoDB: Buffer pool(s) load completed at 170616 23:52:16
            2017-06-16T23:52:16.125127Z 0 [Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
            2017-06-16T23:52:16.125160Z 0 [Note] Server hostname (bind-address): '’; port: 3306
            2017-06-16T23:52:16.125201Z 0 [Note] - '’ resolves to '’;
            2017-06-16T23:52:16.125259Z 0 [Note] Server socket created on IP: '’.
            2017-06-16T23:52:16.138347Z 0 [Note] Event Scheduler: Loaded 0 events
            2017-06-16T23:52:16.138596Z 0 [Note] /usr/sbin/mysqld: ready for connections.
            Version: '5.7.18-0ubuntu0.16.04.1’ socket: ’/var/run/mysqld/mysqld.sock’ port: 3306 (Ubuntu)

Watching htop has been helpful. Occasionally I will see spikes in memory and CPU usage to 100%. Unfortunately, I have no idea what I’m looking at or should be looking for.

  • @semipro Great, we’re getting somewhere.
    The green row at the top of the list, starting with PID, is actually columns, which can be clicked to sort (by default it’s sorted by CPU usage).
    The list will show all processes sorted by whatever column you’ve selected. So you have to look at the list, when it spikes, to see which process is peaking.

And finally the last few lines of the command are below. Sorry I would not allow me to place it all in one post.

2017-06-16T23:52:16.138611Z 0 [Note] Executing ‘SELECT * FROM
2017-06-16T23:52:16.138616Z 0 [Note] Beginning of list of non-natively partitioned tables
2017-06-16T23:52:16.172504Z 0 [Note] End of list of non-natively partitioned tables
2017-06-16T23:52:16.707901Z 3 [Note] Access denied for user 'root’@'localhost’ (using password: NO)

  • @semipro
    Okay, so MySQL hasn’t crashed recently - or it’s outside the log. You could have everything within one comment if you used the code button </> in the toolbar.

I’ve been monitoring htop for 15 minutes now and haven’t noticed any more spikes. If I go to my homepage the CPU quickly jumps to 20% - 40% before going back to 1%. The memory goes up to just under 600M.

Currently everything is running fine with no database errors but I’m certain it will occur again.

What’s using the most memory is /usr/sbin/mysqld at about a constant 17.5%.

/usr/sbin/apache2 -k start at 10%

and then /usr/lib/snapd/snapd and /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/ -x -b are both using 1-2%

  • @semipro
    Okay, that’s weird. It’s normal that the CPU spikes, when you walk around the website, since WordPress is a pretty big framework and loads on each page view.
    The most interesting thing would be to track whatever that suddenly eats all the RAM, since that’s definitely not normal.
    From the log you posted before, it seems like MySQL’s database should keep below 128MB RAM (plus a little overhead cache/etc, so something like 150-200MB) if the tables loaded in WordPress are InnoDB.

    • Okay, I’ll leave htop open and if/when my website has the database error again I will report my findings back here. It seems to go through cycles. I first noticed this issue 2 days ago. Thought I fixed it and then it began happening again yesterday. Rinse and repeat until I made this post.

      Also, I have another site hosted on digital ocean running the exact same setup except it’s not with CloudFlare. The memory usage is nearly 25% lower on average. It has the same theme and mostly the same plugins.

      Thanks for all the help and patience.

      • @semipro
        Any specific time? It could be a task in the crontab - or if your website is being indexes by bad spiders (where they hit every page on your site at the same time).

        • I’ll make a note of the times but I’ve noticed it in the evening and in the morning.

          I don’t understand why this site is running 150-250 higher on memory than the other.

          I’m going to begin disabling plugins and continue to monitor.

Install htop on the other server as well. It doesn’t cost any RAM or CPU, when it’s not running. Then look at the differences in like Apache, MySQL, etc.

Are you running the same version of Ubuntu, Apache, PHP and MySQL on both servers?

When MySQL crashes, then before starting it again, run tail -50 /var/log/mysql/error.log

Hey, everyone, I’m back. So basically I’m still ocasionally running into the same problem. I have five different digital ocean servers. Three of them run perfectly fine on $5 servers with more traffic and web pages. There’s absolutely no reason this $10 server should be running out of memory.

I’ve been routinely monitoring htop and at no point does my memory reach the upper limits. However, for some reason, my error log is showing my server as running out of memory.

I even went so far as to make a snapshot of my data and create a new droplet, put that snapshot on a new server. This hasn’t made things any better.

It has to be one of my plugins or somehow my database is messed up. I’m considering making a new droplet and recreating my website from the ground up. It’s only a few pages so it won’t take too long. However, I don’t want to have to resort to this.

Hello, all

You will most definitely need to upgrade your droplet as you’re running out of memory and your application/website needs more resources in order to continue to operate.

What you can also do is to use the MySQLTuner script.

The MySQLTuner is a script written in Perl and allows you to quickly test your MySQL configuration and it gives you suggestions for adjustments to increase performance and stability.

According to the official GitHub page, it supports 300 indicators for MySQL/MariaDB/Percona Server in this last version.

To run the script you could do the following:

  • SSH to your Droplet
  • Download the script:
wget -O
  • Then execute it:

The script would run multiple checks against your MySQL instance, all checks done by MySQLTuner are documented here.

Also as stated in the official documentation, it is still extremely important for you to fully understand each change you make to a MySQL database server. If you don’t understand portions of the script’s output, or if you don’t understand the recommendations, you should consult a knowledgeable DBA or system administrator that you trust.

As a good practice make sure to always test your changes on staging environments before implementing them on your production database.

On the same note, if you want to have a worry-free MySQL hosting and focus on your application, I would recommend trying out the DigitalOcean Managed Databases:

This was mini tutorial was posted from bobbyiliev in this question in our community:

You can also create a simple bash script to check if MySQL is running and if not to restart it.


# Check if MySQL is running
sudo service mysql status > /dev/null 2>&1

# Restart the MySQL service if it's not running.
if [ $? != 0 ]; then
    sudo service mysql restart

Run this script every 5 minutes using a cron job like this one:

 */5 * * * * /home/user/scripts/ > /dev/null 2>&1

Hope that this helps!