• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Ram consumption very high

I will contact the seller.
Once I had restarted Apache. Then the problem was gone.
That would be more of a sign that it's not the provider's fault.
I can test that again.
Thank you for the detailed help.
 
No, the CPU load is not a good measure for this. You have to take into account the niceness of the process.
For example, it doesn't hurt at all if the system uses all available CPU power for compression threads.
How would that work? I mean, if little or no time is left for other tasks why would a full load not influence the behavior of the system? It won't stop other tasks, but yet they'll take much longer to execute, even if their priority is higher, because a higher priority does not automatically grant them the right-of-way before all others. It's more like they are getting more cars over the bridge than other processes, but not all. If other processes would not clog up the lane, the other processes cold pass much faster.

But again, I agree that likely here the issue is on the machine, not the client's virtualization environment. It just makes no sense that his environment neither utilizes all RAM, nor cpu, yet it becomes unresponsive. It can only mean that other components are causing a wait.
 
iostat 10 -had not worked.

grep "cron.daily" /etc/crontab
3 0 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

I will test it and I will contact the provider.
Once during the problem I had restarted Apache. Then the problem was gone.
That would be more of a sign that it's not the provider's fault.
I can test that again.
Thank you for the detailed help.
 
In /etc/cron.daily/50plesk-daily
stands
/opt/psa/bin/sw-engine-pleskrun /opt/psa/admin/plib/DailyMaintainance/script.php >/dev/null 2>&1
The path /opt/psa/admin/plib/DailyMaintainance/script.php is there.
The screenshot does not show the path /opt/psa/admin/plib/DailyMaintainance/script.php, but the path /opt/psa/admin/plib/DailyMaintainance/task-script.php
There is no file task-script.php in the path. Or am I not seeing that correctly?
 
How would that work? I mean, if little or no time is left for other tasks why would a full load not influence the behavior of the system? It won't stop other tasks, but yet they'll take much longer to execute, even if their priority is higher, because a higher priority does not automatically grant them the right-of-way before all others.
A process can't "just" run, it always has to go through the scheduler, even if no other processes are running. And the scheduler will not preempt a high-priority task for lower-priority ones. But all free time will be distributed across the lower levels in the same manner.
So a high CPU load by itself will not influence higher-priority processes. But there's still the issue that other processes usually also use RAM and I/O bandwidth, and that can also influence the higher-priority processes.

iostat 10 -had not worked.
On debian, it's in package sysstat, so I'd guess apt-get install sysstat also works on ubuntu.

There is no file task-script.php in the path. Or am I not seeing that correctly?
Probably generated by the other script, then executed and deleted.
 
Back
Top