Search results

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?

favicons are stored most persistent in caches, because they rarely change. It's a cache issue only (which you already found out). What you can do is to load the icon file via it's URL separately, add a question mark and a random character to the URL, reload that URL. That should fix it without...

Why is the system still using the same mirror?

Did you follow any of the recommended steps that I have painstakingly put together for you?

The relevant part is: Status code: 404 ... elfutils-debuginfod-client-0.192-6.el9_6.alma.1.x86_64.rpm It means that in the mirror you are using the required resource does not exist. You can try to refresh the dnf cache, e.g. dnf clean all rm -rf /var/cache/dnf dnf makecache dnf update Then...

Maybe iptables is used? That's something you cannot start or stop. Try # iptables --list -n | less to see the rules that are filtering traffic. A banned IP will not have been banned by ImunifyAV, but by Fail2Ban. This is not the "Plesk Firewall", but "Security"->"IP Address Banning".