zend opcache php-fpm

[zoni]

Hello,

I have a number o WordPress sites in different hosting accounts within the same sever with plesk 12.5

All are php 5.6.17 as FPM served by apache.

I have installed a wordpress plugin called OPcache Dashboard.

With this plugin you can see which scripts are cached.

Is it normal that I can see the scripts from other sites hosted on the server?

Is there a way to prevent this like having zend opcache to have a cache for each vhost separately?

Thanks.

 

[esbon]

Hello zoni, I've noticed the same only after I migrated to Plesk 12.5 as a result of the memory needed by opcache is at 3 times more. I also think I should only see scripts only from the site OPcache Dashboard is installed. Have you found any info on how to isolate OPcache on a domain basis? By the way, I am running sites with FPM Application handler

Please share if any new info has come up, thanks

 

[zoni]

Hello esbon,

Unfortunately I have found no solution for this. Currently I am more worried about plesk scheduled backup killing apache every time a full server backup is performed.

Well about opcache in plesk, currently it works in a shared memory and is perfectly possible for it to work in each vhost home folder at least is what this guys do for cpanel.

 

[esbon]

Thanks for sharing

 

[trialotto]

@esbon and @zoni,

If you want me to, I can have a look at the issue in due time.

There are two approaches possible: have a look at the code of the WordPress plugin or have a look at the Opcache settings.

Which of the approaches do you prefer? WordPress based approach?

Just let me know.

Regards.....

 

[esbon]

Hi Trialotto, I think each domain should be have its own root level opcache files so other domains can't see the scripts being cached by other users
Best regards,

Miguel

 

[zoni]

Hi trialotto,

I am with Miguel, this shoud be done for a better security

I have already open a sugestion in user voice

 

[trialotto]

@esbon and @zoni,

I also agree with you that opcache data should be "secure", in the sense that specific information should be shielded and not be visible.

There is the possibility for you (both) to suggest this improvement on plesk.uservoice.com.

In the meantime, I will have a look and investigate whether this issue is related to Plesk or, more general, to OpCache, and/or, in specific, to the WordPress plugin.

For that reason, I have to ask you

- which WordPress plugin(s) did you use?
- are you using shared hosting or running your own Plesk Panel?

Regards........

 

[esbon]

I am running Plesk 12.5 with FPM Application handler, PHP 5.6, CentOS 7, and the WP plugin is the OPcache Dashboard. I must say I just upgraded this panel from Plesk 12 and this did not happen with the same setup

 

[zoni]

Hi,
Miguel, it did not happen in previous version of Plesk but it does not have to do with plesk itself but probably because you were using php fastcgi.

Trialotto, I have already submit this in user voice: link here

In my case I provide hosting with plesk 12.5 in centos 7.

You can find the mencioned plugin here

 

[esbon]

zoni, I switched a couple of domains back to PHP FastCGI and the problem does not happen; it also uses a lot let memory.

 

[trialotto]

@esbon and @zoni

The older versions of Plesk 12 did not have OpCache enable by default, at least on the "older" PHP versions.

Moreover, it is available on PHP > 5.5.x as a Zend extension, implying that the module has to be loaded.

Regards....

 

[esbon]

Yes, in my case I was using the remi, epel repos for PHP 5.4 where I was able to yum install OpCache and the module would load by default after that

 

[trialotto]

@esbon and @zoni,

There is this "nature" of OpCache: in essence, it is "shared memory" by design.

Naturally, options exist to disable OpCache on a per-domain level, but this is not exactly what we are looking for and/or are trying to do.

The above implies that some alternative work-around has to be created and, as far as I know, that is not an easy thing to do in this situation.

I will keep you updated.

Regards.....

 

[esbon]

Since OpCache is important to all of our Wordpress sites, I will just move all domains back to PHP FastCGI until it is safe to use OpCache without the leaking scripts among domains.

Best regards

 

[trialotto]

@esbon,

You can safely use FPM, with OpCache disable on every domain: you can do that on all domains or disable OpCache in the general .../php/<version>/etc/php.d/10-opcache.ini file.

In short, there is no need to return to FastCGI.

Regards....

 

[trialotto]

@esbon (and @zoni),

A quick work-around is available: add the line

opcache.restrict_api = <directory>

to the /opt/plesk/php/<version>/etc/php.d/10-opcache.ini file, with <directory> a custom value: you can use /home/admin if you do not know an appropriate directory.

Afterwards, a restart of the plesk-php<version>-fpm service is required.

As a final remark, a more elaborate explanation will follow later, somewhere on this forum. I will keep you posted.

Regards.....

 

[esbon]

Thanks for the tip. Sure I can disable OpCache, but the thing I liked about PHP5.5 and 5.6 was that OpCache was loaded by default and Wordpress sites only needed to install the OpCache plugin.

 

[trialotto]

@esbon

The work-around still allows OpCache to work properly, but only restricts access to specific functions.

Regards

 

[iMadalin]

For all that know their stuff around Linux and manually control PHP, you can create separated PHP-FPM services and assign them one per client.

Each client having it's own PHP-FPM service, will provide isolation > security, stability (if a client has a script that stalls the PHP-FPM service, the other clients won't be affected) and better performance (you can manually tweak priorities, and also benefit from CGROUPS per service, so you can put some real hard limits on processes).

(I'm currently doing it so it's working and have really happy clients).

This should be offered as a choice in future Plesk versions. I would hope for this on Plesk 17, or even better, use docker to provide PHP-FPM per website (if you afford more ram).

Problem solved