• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

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