Search results

Thank you, I'll try it on a few servers. So far I have "AllowStoreRestart On" on all, but I did not yet have "DeleteAbortedStores Off". The latter might cause new issues when a truly interrupted backups cannot be resumed, because then partial backup files might occupy space on the external FTP...

Backup Manager: A full backup takes hours, during that time period we experience short network connectivity issues to the external FTP storage space. These are probably short, maybe a minute, maybe two. But they are long enough that the backup manager thinks, the connectivity is lost and ends...

Either Mod_Security (web application firewall) is blocking access (you can tell from an error.log entry of the 403 error code) or the permissions of the document root directory of the website are wrong. They must be <subscription user account name>:psaserv, not psacln.

I sometimes ask myself why I give detailed to-do descriptions when all that results is just a repetition of "something's wrong" ...

Yes, but what could I use the information for?

On the other thread I already suggested to look at Apache's RAM usage and to limit it so that it can never exceed a certain value. If Apache is consuming a lot of RAM, it either has spawned too many children or PHP processes executed by it occupy the RAM. So first check Apache, then go after PHP...

I like these directives. For the dashboard it should also be OK, because they cause limited load only. The reverse lookups should be an option. These could take a lot of time. What's the exact benefit for the administrator seeing the outputs? (What's the business case where the information is...

It doesn't release the cache, because it does not need to release it. From MariaDBs perspective, it has plenty of RAM left. The problem is that the system starts occupying RAM outside MariaDB, and that triggers OOM to kill MariaDB, because that memory manager thinks it needs to clear RAM. But...

Excellent point. In that case you might have an enormous number of files in some subfolder. They might be small, but many, for example a million or more files of only a few bytes each. This could match your symptoms, because in that case, it "feels" like the backup doesn't move on, but in...

More ideas: The screenshot mentions update errors. It is possible that you see the correct version in the GUI, but an update was never fully completed. You could try to manually run the Plesk update again. It will just overwrite missing parts. Further, the "invalid updateTicket" can mean that...

No, it does not, and you know it does not, because we already went through this in the other thread.

This! Examine swap.

20 GB + 7.4 GB = 27.4 GB. Your total RAM: 40 GB The RAM manager does not kill MariaDB, because MariaDB occupies all RAM. It kills MariaDB as one out of several measures, because the total RAM usage exceeds a limit. MariaDB is not your problem. But I've written it now several times, pointing...

It means that MariaDB itself doesn't hit the RAM limit, but other processes on your server occupy so much RAM that the RAM manager on the server kills MariaDB. Stop looking for issues with MariaDB, fix the other processes, which are most likely PHP and Apache.

If you limit Apache RAM usage, Apache will not be able to spawn new child processes once it reaches the limit. It will also not be able to process new web requests until some RAM is freed again. However, for Apache this will happen quickly. Surfers will notice that they cannot reach the website...

For MariaDB your charts just don't show that it's occupying too much RAM. It's perfectly alright that it uses a few more GB than what the InnoDB cache got. In an overload situation, when the website gets many hits, naturally the process number against MariaDB also increases. The reason why on...

None of the charts shows that RAM is maxed out. The maximum that your MySQL is using are approx. 18 GB. But you said your server has 40 GB. The real memory usage is ordinary. Nothing special to see there. There is no RAM issue. The CPU usage is at around 100% at the times when PHP and Apache...

You said, MySQL only accounts for 25% of the RAM (10 GB). So what is the real situation? Are you saying that MySQL occupies all available RAM? Can you prove this, e.g. with a monitoring chart?

The database is fine. You'll need to find out why your website (the webserver, hence PHP-FPM processes) request so much RAM. In general, a "£2m a year website" seems to deserve a proper RAM size anyway. But what's really happening is that your site is getting hit by persumably a lot of real...

Please describe "memory allocation issues" in more detail. What exactly is happening?