Forwarded to devs Plesk updates website configuration concurrently instead of sequential

[Tozz]

TITLE:

Plesk updates website configuration concurrently instead of sequential​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Plesk Onyx 17.8.11
Debian 9
amd64/x86_64​

PROBLEM DESCRIPTION:

When we made adjustments to default PHP config, for example /etc/php/7.0/cgi/php.ini we need to inform subscriptions about these changes. In order for us to do this we run:

/opt/psa/bin/php_settings -u

This updates all php.ini files for all subscriptions with the updated version as is expected. However, this also executes some sort of async process.

On servers with a high domain count (eg. over 500) this is causing the server to run out of memory, each max process count, unable to fork errors, etc, etc. We sometimes see over 3000 of these 'async plesk processes' that spit out errors like unable to fork.

Additionally, this sometimes seems to trigger some kind of race condition in FPM that causes FPM to hang​

STEPS TO REPRODUCE:

1. Create a plesk machine with a high domain count (over 500) with PHP enabled.
2. Run /opt/psa/bin/php_settings -u
3. In another session, see your process counter go skyhigh. Server load goes through the roof, etc, etc.​

ACTUAL RESULT:

1. the async process sometimes fails to fork, possibly resulting in sites not properly adjusted.
2. Server reaches max process count
3. Server gets very slow and very busy
4. Sometimes triggers a race conditiion in FPM, where fpm requires a manual restart​

EXPECTED RESULT:

The 'Plesk async process' should be run sequentially (one domain after another) and the processes should be queued.

Now it seems they are all fired after another as a seperate process/thread. This isn't an issue on a server with maybe 100 domains, but it is on servers with lots of domains.​

ANY ADDITIONAL INFORMATION:

​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Confirm bug​

 

[Tozz]

I ran "php_settings -u" today on a machine:

# ls -1 /var/www/vhosts/system/ | wc -l
757

While it is running we can see the process count go up:

root@saturn:~# date ; ps -aux | grep event_handler  | wc -l   
Mon Nov 12 15:28:44 CET 2018
428
root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:28:44 CET 2018
431
root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:28:45 CET 2018
439
root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:28:47 CET 2018
448

--- cut ---

root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:31:22 CET 2018
1419
root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:31:30 CET 2018
1448
root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:31:45 CET 2018
1511

--- cut ---

root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:34:00 CET 2018
1688
root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:34:02 CET 2018
1692
root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:34:05 CET 2018
1697
root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:34:08 CET 2018
1687
root@saturn:~# date ; ps -aux | grep event_handler  | wc -l
Mon Nov 12 15:34:10 CET 2018
1682

And ps -x shows:

32170 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis
32172 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis
32189 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis
32205 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/modules/wp-toolkit/library/EventListe
32244 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis
32252 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/modules/wp-toolkit/library/EventListe
32267 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis
32275 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/modules/wp-toolkit/library/EventListe
32298 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/modules/wp-toolkit/library/EventListe
32313 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis
32315 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis
32332 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis
32341 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis
32343 ?        Ss     0:00 /opt/psa/admin/bin/event_handler -i -u psaadm /opt/psa/admin/bin/php -- -f /opt/psa/admin/plib/scripts/interface_async_executor.php -- EventListener /opt/psa/admin/plib/registry/EventListener/wpConfigPermis

This looks like event being triggered. To clarify, we don't have any special events regarding PHP:

root@saturn:~# /opt/psa/bin/event_handler -l
   Id               1
   Name             Mail account created
   Priority         0
   User             root
   Command          /opt/plskevents/enable_dkim

   Id               2
   Name             Domain created
   Priority         0
   User             root
   Command          /opt/plskevents/fix_dns

root@saturn:~#

 

[IgorG]

Here is the developer's explanation:

I do not confirm a product bug here. Update of PHP settings on domains occurs sequentially, not concurrently.
Event listener calls are performed asynchronously unless it is customized in panel.ini

[eventListener]
syncExecution='on'

According to customer's output, a big number of processes is introduced by listener wpConfigPermissions that was delivered in MU for 11.5.
This listener creates a new process on every Plesk event and is completely useless now so it is proposed to delete /opt/psa/admin/plib/registry/EventListener/wpConfigPermissions.php

WordPress Toolkit listener creates new process only for events that are important for WordPress Toolkit functionality. The only way to avoid such processes is by removing (disabling) WordPress Toolkit extension.

 

[Tozz]

Okay, so this is not a bug but expected behaviour?

If that is the case, why isn't the syncExecution parameter documented anywhere? That could have resolved our issues.