• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Questions with OPCache

Edu Membrillas

New Pleskian
I have been working with OPCache for some time, but I have had a few doubts due to a series of problems that I detail below.

I have an Ubuntu server with a PLESK installation where I have about 50 domains hosted. I have OPCache activated, but most of the time the memory for opcache is full and there are pages that are not cached and I have to reset OPCache and I have the same problem again.

I have configured the file php.d / 10-opcache.ini and among other parameters, I have changed the limit of opcache.memory_consumption to 1024 and it seems that now the memory limit holds for all domains.

My Doubt is:

Can I put a limit per domain and that the server has no limit?
 
It should be possible by setting the desired opCache variables in the PHP settings of your domain's PHP configuration.
These will be placed in the domain's PHP configuration file, so these values apply on a domain basis and not on a service basis. Values that you place into the ini files affect all domains as default values.
 
As far as PHP-FPM is concerned, you can't set opcache.interned_strings_buffer per domain - that's set per pool.

In theory, opcache.max_memory_consumption can be set, but I've seen this directive to be very troublesome. There's an unpatched bug that results in negative memory values if pool mem > per-domain mem, or otherwise the memory being displayed as used. See: #869431 - php7.0-fpm: Decreasing opcache.memory_consumption in pool-file causes negative "used memory" - Debian Bug report logs

Unfortunately, the best solution would be per-domain/subscription PHP pool/master processes, which plesk doesn't support.
 
As far as PHP-FPM is concerned, you can't set opcache.interned_strings_buffer per domain - that's set per pool.

In theory, opcache.max_memory_consumption can be set, but I've seen this directive to be very troublesome. There's an unpatched bug that results in negative memory values if pool mem > per-domain mem, or otherwise the memory being displayed as used. See: #869431 - php7.0-fpm: Decreasing opcache.memory_consumption in pool-file causes negative "used memory" - Debian Bug report logs

Unfortunately, the best solution would be per-domain/subscription PHP pool/master processes, which plesk doesn't support.
Correct. This is a problem, because if I have 40 domains on my plesk server and with 30 I reach the memory limit, 10 are left without caching. What would be the best solution? Discarding raising the memory limit.
 
Because the server have 5 gigas of ram, and if 50 sites already consume 100Mbs/site of memory ... just by calculation I understand that there is not enough memory.
 
I don't see how that makes a difference.
50 sites using 100MB, or 50 sites using 2MB each. Same thing.


If you really want to, you'll need to modify how Plesk provisions fpm pools.
 
I don't see how that makes a difference.
50 sites using 100MB, or 50 sites using 2MB each. Same thing.


If you really want to, you'll need to modify how Plesk provisions fpm pools.
It is a good reflection that I have also made. But thinking about it, I prefer 50 sites cached at 80% than 40 sites at 100% and 10 sites without caching, and also, to be able to do an opcache_reset of a single site without having to empty the others.

On the other hand, I have a doubt, the 50 installations are 50 wordpress, all with the same version of WP, is there any way that these files are cached only once and are valid for all sites? With this I understand that I would not care about everything else.
 
No, you can't, and don't want to do this for good reason. If site X is cached first and his wp core is infected, that is going to propagate to all sites, which is very bad. Users cannot share opcache files, and shouldn't.

You can use opcache preloading to preload certain filez, but that needs to be done for each site still.

Your own solution is to not use FPM, or split up the pools.
 
I have been reading the article and I understand that although separating PHP-FPM for each domain is the best, but that PLESK can not be done with right now.

On the other hand, would using FAST-CGI change something?

I want to thank you john0001 for taking the trouble to deal with this issue, it is something that interests me a lot but there is not much documentation about it.
 
Lack of documentation, and even fixes for certain bugs is definitely an issue. It's not so much of a plesk thing, rather how FPM/opcache handles memory.

Using FastCGI would defeat the point of opcache. FastCGI spins up a new thread per process, and has no persistent cache.
 
Lack of documentation, and even fixes for certain bugs is definitely an issue. It's not so much of a plesk thing, rather how FPM/opcache handles memory.

Using FastCGI would defeat the point of opcache. FastCGI spins up a new thread per process, and has no persistent cache.
oh! Okay. Now I understand why when using the opcache with sites with FAST CGI, this opcache is cleaned up when the thread is closed. I saw it, but did not know why it happened.
 
Yeah. As far as that goes, there's no good solution to your problem. I've played around individual pool/masters per site, but that creates more problems that it's worth, for me at least.
 
I have also been testing and testing, but as you say, it is complex. Hopefully OPcache continues to advance and Plesk hand in hand to get the best configuration with the best performance. The truth is that the web pages under OPcache go very fast, but the memory consumption scares me a bit.

Thanks again for this thread and for shedding some light on some of my doubts. I will be happy to continue debating and talking about this topic. :)
 
As far as large OpCache pools go, the tradeoff of no-cache vs some cache is pretty obvious - having 80% of users cached is much preferable to zero (w/ OpCache enabled). I've had big (many GB) pools with no problem.
 
Back
Top