• 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 Plesk Runs Multiple Instances of a Single WordPress Installation?

jase42

New Pleskian
I recently migrated a client's website from VPS A to VPS B, and now that it is moved to VPS B I see that Plesk is running the website's instance multiple times.

The VPS is a dual core 2GB RAM server and has never had performance issues previously.

Using
Code:
ps aux | grep safe_mode | grep -v grep

I can see that the recently migrated WordPress instance is running multiple times.

h78g2vf+ Is the suspect WordPress installation

s782bg3+ & us82bco+ are two other WordPress installations on the same server that work fine.

Code:
top - 12:36:46 up  1:01,  1 user,  load average: 5.12, 5.28, 5.39
Tasks:  62 total,   8 running,  54 sleeping,   0 stopped,   0 zombie
%Cpu(s): 61.0 us, 35.6 sy,  0.0 ni,  3.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  2097152 total,   133488 free,  1017484 used,   946180 buff/cache
KiB Swap: 33554428 total, 33554428 free,        0 used.        0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 4930 h78g2vf+  20   0  694188 164484  47164 R   5.8  7.8   1:44.63 php-fpm
 4928 h78g2vf+  20   0  694216 163868  46492 R   5.5  7.8   1:44.37 php-fpm
 4926 h78g2vf+  20   0  694028 167828  50612 R   5.2  8.0   1:44.71 php-fpm
 4927 h78g2vf+  20   0  691048 163736  49564 R   5.2  7.8   1:43.05 php-fpm
 4940 h78g2vf+  20   0  693584 169532  52768 R   5.2  8.1   1:43.57 php-fpm
 6644 us82bco+  20   0  469048  41260  22944 R   4.2  2.0   0:00.13 php-fpm7.2
 6640 s782bg3+  20   0  466624  38228  23092 S   2.6  1.8   0:00.20 php-fpm7.2
  655 mysql     20   0  721684 182616  11004 S   1.3  8.7   0:43.11 mysqld
 4897 www-data  20   0 1344588  20384   4144 S   1.0  1.0   0:05.25 /usr/sbin/apach
  546 root      20   0   72284   3392   2640 S   0.3  0.2   0:01.08 sshd
 5966 root      20   0   36616   1916   1364 R   0.3  0.1   0:00.96 top
    1 root      20   0  159476   6080   3956 S   0.0  0.3   0:08.90 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd/875323
    3 root      20   0       0      0      0 S   0.0  0.0   0:00.00 khelper

Here is a graph of the server's CPU status; the slight dip after the 12 hour mark is when I disabled the WordPress instance and then re-enabled it.

CdA0TLE.png


I have fully updated the affected WordPress installation, I have rebooted the server multiple times to no avail.

The affected WordPress installation is a low traffic site which receives 50-100 views per day. The database has been optimised.

Any thoughts/ideas?
 
If I have to guess, check your php settings & version on the domain and subscription to find the difference to the other domains

Helpfull would be also some more details about OS & Plesk Version
 
Last edited:
Is there anything in the vhost logs that would explain this? PHP warning or errors or a bot attack?
 
Referring to the number of instances: I can see a normal behavior. It is definitely possible that the same site creates several PHP-FPM instances. Nothing to worry about this. A new instance is created at least every time when one instance is "busy" while the next request needs to be processed. You can set the maximum number of instances on the PHP settings page. By experience I recommend to set rather a higher than a lower number, e.g. for many customers here the default setting of 5 is too low, 25 is better for them.

Referring to the load: Most likely a bot attack, but check the access_log on this.
 
Back
Top