Joomla websites keep loosing connection to databases (I think)

nginx log sample line

2017/06/20 15:37:26 [error] 20796#20796: *11706 FastCGI sent in stderr: "PHP message: PHP Warning:  session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/sessions) in /var/www/ on line 194" while reading response header from upstream, client:, server:, request: "GET //jreviews/videos?m=6b22D HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: ""

Here is what you see -

The error is so bad the application fails and this has been linked to a connection problem with the database. Is it possible the connection dies. It is intermittent and quite frequent.

Thanks for any help…this is going to kill my SERPS that aren’t great and one of the reasons for moving to DO.

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.

With the memory issue and the database quits - does this damage the data?


This is what I thought I’d see:

2017-06-21T15:43:49.711386Z 0 [ERROR] InnoDB: mmap(137428992 bytes) failed; errno 12
2017-06-21T15:43:49.711400Z 0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool

The first error specifically means that MySQL isn’t able to allocate the RAM it needs to continue to function normally, thus it crashes. In this specific scenario, you need to upgrade to at least 1GB of RAM so that MySQL has the RAM it needs to function normally.


The issue looks to be more so with PHP than it does MySQL, at least from the error in your post. You can check the MySQL error log by running:

tail -25 /var/log/mysql/error.log

If that doesn’t work, you may need to adjust the path depending on the directory that is used by your version of MySQL.

You should be able to do an ls on the /var/log directory to find the correct one.

ls /var/log

From there, we can see if MySQL is actually crashing and if so, what is being logged. If we find that MySQL is crashing, it’s most likely due to limited RAM, in which case I’d recommend upgrading your Droplet to the next size up. So if this is a 512MB Droplet, upgrade to a 1GB Droplet.

Optimizations can be done on smaller Droplets, though it’s constant and on-going. It’d be far easier to upgrade and add free RAM to what’s available unless your comfortable modifying core configuration and troubleshooting.

That said, since this is an [error] and not a [warning], it’s something you need to fix. Generally when PHP can’t write to the sessions directory, it either doesn’t exist or you simply don’t have permission to write to it. That seems to be the case here.

If you run:

ls -al /var/lib/php

the ./sessions directory should be owned by root and have default permissions of drwx-wx-wt. If you seen any variance there, then that may very well be the cause.

In most cases, it’s better to actually write session data to another directory, other than the global, if possible. In some cases this can be configured by the script or application, in others, there are no direct options to do so. You’d have to check and see if Joomla supports this. If it does, you could simply create a new directory below your public directory and call it session and change to use that directory. That way you’re in full control over the directory and how it’s handled.