Server leaks memory and crashes on Ubuntu 16.04 using WordPress

July 5, 2017 129 views
Server Optimization

Hello,

I have a WordPress website that have been running 3 months on DO without any problems. Today it crashed?! I couldn't connect through SSH (sshexchangeidentification: read: Connection reset by peer. It didn't accept my connection).

I restarted the server and now it's giving me memory leak and mysql can't start. This is driving my crazy. Any suggestion? Support tickets takes way to long to get any useful feedback from.

Thank you!

2 Answers

Hi @marcustisater

Which OS are you using? Which version of PHP+MySQL? Have you kept all services up-to-date?
How big is your droplet? And are you running big plugins in WordPress?

Where is it saying something about "memory leak" ?
Can you post the last 40 lines of your MySQL error log:

tail -40 /var/log/mysql/error.log
  • Thanks hansen for your assist. Well I assume it leaks memory because it outputs -bash: fork: Cannot allocate memory.

    Here is my log from mysql

    2017-07-05T18:30:59.573505Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
    2017-07-05T18:30:59.573510Z 0 [Note] InnoDB: Using Linux native AIO
    2017-07-05T18:30:59.574586Z 0 [Note] InnoDB: Number of pools: 1
    2017-07-05T18:30:59.575852Z 0 [Note] InnoDB: Using CPU crc32 instructions
    2017-07-05T18:30:59.588178Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
    2017-07-05T18:30:59.588640Z 0 [ERROR] InnoDB: mmap(137428992 bytes) failed; errno 12
    2017-07-05T18:30:59.588658Z 0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
    2017-07-05T18:30:59.588665Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
    2017-07-05T18:30:59.588675Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
    2017-07-05T18:30:59.588681Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
    2017-07-05T18:30:59.588688Z 0 [ERROR] Failed to initialize plugins.
    2017-07-05T18:30:59.588693Z 0 [ERROR] Aborting
    
    2017-07-05T18:30:59.588706Z 0 [Note] Binlog end
    2017-07-05T18:30:59.595206Z 0 [Note] /usr/sbin/mysqld: Shutdown complete
    
    2017-07-05T18:31:29.564205Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000)
    2017-07-05T18:31:29.564354Z 0 [Warning] Changed limits: table_open_cache: 431 (requested 2000)
    2017-07-05T18:31:30.628607Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
    2017-07-05T18:31:30.637943Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.18-0ubuntu0.16.04.1) starting as process 2530 ...
    2017-07-05T18:31:31.147188Z 0 [Note] InnoDB: PUNCH HOLE support available
    2017-07-05T18:31:31.147235Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    2017-07-05T18:31:31.147240Z 0 [Note] InnoDB: Uses event mutexes
    2017-07-05T18:31:31.147247Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
    2017-07-05T18:31:31.147253Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.8
    2017-07-05T18:31:31.147258Z 0 [Note] InnoDB: Using Linux native AIO
    2017-07-05T18:31:31.148261Z 0 [Note] InnoDB: Number of pools: 1
    2017-07-05T18:31:31.149163Z 0 [Note] InnoDB: Using CPU crc32 instructions
    2017-07-05T18:31:31.153048Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
    2017-07-05T18:31:31.155277Z 0 [ERROR] InnoDB: mmap(137428992 bytes) failed; errno 12
    2017-07-05T18:31:31.155306Z 0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
    2017-07-05T18:31:31.155314Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
    2017-07-05T18:31:31.155326Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
    2017-07-05T18:31:31.155332Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
    2017-07-05T18:31:31.155340Z 0 [ERROR] Failed to initialize plugins.
    2017-07-05T18:31:31.155345Z 0 [ERROR] Aborting
    
    2017-07-05T18:31:31.155353Z 0 [Note] Binlog end
    2017-07-05T18:31:31.156504Z 0 [Note] /usr/sbin/mysqld: Shutdown complete
    

    No really big WordPress plugins, it was all up to date as well. My droplet is 1 GB Memory / 30 GB Disk on LON1

    • @marcustisater

      "Cannot allocate memory" means there's no more free memory. That's not the same as leakage.
      Try running the command top to list processes currently running - there you can see how much CPU and memory each consume.

      Which OS are you using? Which version of PHP+MySQL? Have you kept all services up-to-date?
      Are you running Apache or Nginx?

      Besides those services and WordPress, is the server running anything else?
      From what I can see, your server is simply low on memory and crashes the biggest consumer of that, which generally always is the database.

      • Sorry I am not that experienced :-) It's DO one click install for WordPress so it's running the latest mysql version and php7. It's all on Ubuntu and on Apache.

        It's just WordPress running.

        It's wired. From what I see from whats running on the server nothing is causing the leak.

        I am all out of ideas. Do you have any drastic options I can proceed with? Thanks once again

@marcustisater

If you're using the one-click WordPress app that allows a 512MB Droplet to be used, that would most likely be the issue since MySQL requires quite a bit of RAM.

These two errors are the ones I look for within the error logs:

2017-07-05T18:31:31.155277Z 0 [ERROR] InnoDB: mmap(137428992 bytes) failed; errno 12
2017-07-05T18:31:31.155306Z 0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool

Anytime you're seeing those two errors, you either need more RAM or you need to tune MySQL. In a low-RAM environment, it's not always ease to run a full stack unless you're able to tweak & tune the configuration for each individual piece of software (Apache, PHP, MySQL, etc).

The newer WordPress one-click app that's now available requires at least a 1GB Droplet (512MB is no longer an option) which helps to prevent this, though in some cases, 1GB isn't enough either.

Caching can help to reduce some of the usage (WP Super Cache, W3 Total Cache) by reducing some of the redundant database calls for each page when it hasn't changed though, so that'd be one thing I'd recommend setting up. WP Super Cache is probably the easiest to setup overall.

https://wordpress.org/plugins/wp-super-cache/

https://wordpress.org/plugins/w3-total-cache/

The thing to remember with caching plugins is that you only need one. In this specific case, more is definitely not better :-).

As with any big change -- before installing a plugin you've never used, I'd recommend taking a full backup of your site using a snapshot, that way you can fall back and redeploy to the state the Droplet was in before you installed. Caching plugins generally don't cause issues, though it's always better to be safe :-).

Have another answer? Share your knowledge.