Input Log browser started causing high load

[jorge ceballos]

Hi,

My grain of salt just in case someone happens to be in the same situation...

This past saturday I woke up to find my main server's load over 20 with peaks up to 50.
Long story short: task-async-executor was stuck in task whose id was found in the longtasks but though it was killed several times, it came up again after some minutes and again skyrocketed server's load. Somehow reviewing logs and tables came to the conclusion that the log-browser extension was causing it.
Uninstalled the this extension and everything went back to normal with load under 1.00.

Extension uninstall was done almost 24 hours ago and it came to my attention that IOPs dropped after months of searching why had they suddenly increased with long periods of high activity when in the past they went almost unnoticed as well as swap has also dropped in over 50% of what had been used past months.

Hope it helps and must surely will try log browser extension's next version and see how it behaves.

Regards

 

[AYamshanov]

Thank you for the feedback! It seems an additional load is appearing because of the new feature called Track Email Delivery (https://docs.plesk.com/release-notes/obsidian/change-log/#log-browser-1.8.0). To decrease load during the search and increase the speed of the search itself, the extension periodically aggregates mail logs.

You can disable the feature with the panel.ini option,

[ext-log-browser]
mailQueue.customerAccess = false

We also would love to get any additional information that will help us to investigate the issue (e.g.: how many email addresses it serves? how big log files are on the servers? What hardware is used for the server? OS/Plesk version? Any errors related to the long tasks in the system/Plesk logs?)

 

[jorge ceballos]

Thank you for the feedback! It seems an additional load is appearing because of the new feature called Track Email Delivery (https://docs.plesk.com/release-notes/obsidian/change-log/#log-browser-1.8.0). To decrease load during the search and increase the speed of the search itself, the extension periodically aggregates mail logs.

You can disable the feature with the panel.ini option,

[ext-log-browser]
mailQueue.customerAccess = false

We also would love to get any additional information that will help us to investigate the issue (e.g.: how many email addresses it serves? how big log files are on the servers? What hardware is used for the server? OS/Plesk version? Any errors related to the long tasks in the system/Plesk logs?)

Thanks for your followup.
Yes, You are right, there was something related to email which I did not investigate further as I was running the fix against the clock. When the tasks were klled I expected some kind of reaction related to email delivery but fortunately nothing happened.


This server serves 700 email addresses on postfix
maillog files are 11M
whole /var/log/ is 1.7G
4 x Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz / 16G RAM
psa v18.0.60_build1800240313.13 os_CentOS 7 - I know, we are about to migrate to Almalinux but have too many php7 sites

And no, could not find any error in system or Plesk logs.

Hope this helps.

Regards,

 

[Kaspar@Plesk]

psa v18.0.60_build1800240313.13 os_CentOS 7 - I know, we are about to migrate to Almalinux but have too many php7 sites

Just as a side note, all PHP versions between 5.6 and 8.3 should currently be available on Alma 8 (and 9) with Plesk

 

[jorge ceballos]

Just as a side note, all PHP versions between 5.6 and 8.3 should currently be available on Alma 8 (and 9) with Plesk

I know but the migration script in the preparation step show the following:
Doing preparation checks...

Required pre-conversion condition 'check for not supported PHP versions' not met:
Not supported PHP versions were detected: PHP 7.0.

When running "plesk installer remove --components php7.0" Plesk installer starts working and checking installed packages and stops at:
"You already have the latest version of product(s) and all the selected components installed. Installation will not continue." but php7.0 is still there...

Plan to investigate further how to solve this as soon as have some time left.

Regards,

 

[Kaspar@Plesk]

Thank you for pointing that out. Somehow the script does not recognize PHP 7.0 as a supported version. Which seems a bit odd.

Supported PHP versions are: ['PHP 5.6', 'PHP 7.1', 'PHP 7.2', 'PHP 7.3', 'PHP 7.4', 'PHP 8.0', 'PHP 8.1', 'PHP 8.2', 'PHP 8.3'].

I've asked the developer if this is indented. Will post back when I know more.

 

[Kaspar@Plesk]

I've asked the developer if this is indented. Will post back when I know more.

Support for PHP 7.0 gets added to the next release of the centos2alma script, which is due to be released by the end of this month.

 

[jorge ceballos]

Support for PHP 7.0 gets added to the next release of the centos2alma script, which is due to be released by the end of this month.

Thanks Kaspar !
We'll wait then.

Regards

 

[Kaspar@Plesk]

Just a heads up, version 1.3.3 of the centos2alma script has been published. Which does includes a fix for the PHP 7 issue you where having.

 

[AYamshanov]

A few minutes ago, a new version of the Log Browser extension was released, it contains fixes to reduce CPU usage, and it also provides an additional `panel.ini` option to customize for what period data should be processed (if required).

 

[jorge ceballos]

Just a heads up, version 1.3.3 of the chhhhentos2alma script has been published. Which does includes a fix for the PHP 7 issue you where having

Thanks, downloaded the latest script at: wget https://github.com/plesk/centos2alma/releases/download/v1.3.3/centos2alma-1.3.3.zip

Ran it and 30 minutes later the server updated without a glitch! total time, including the self-reboot was around 40 minutes.

To be honest, I did not mean to run it on a weekday, I was just testing to run it on saturday.... but it just went ahead, I missed the 40 second break and it updated itself. Phew!!
Forgot to mention that Maria DB had already been updated before to v 10.11.8

Thanks a lot to everyone involved.