Recent content by Bitpalast

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?