Req #80812 [Csd]: opcache.cache_id should be PHP_INI_PERDIR
| From: | cmb@php.net | Date: | Tue, 02 Mar 2021 15:54:00 +0000 |
| Subject: | Req #80812 [Csd]: opcache.cache_id should be PHP_INI_PERDIR | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-232477@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=80812&edit=1
ID: 80812
Updated by: cmb@php.net
Reported by: aschmidt at anamera dot net
Summary: opcache.cache_id should be PHP_INI_PERDIR
Status: Closed
Type: Feature/Change Request
Package: opcache
Operating System: Windows
PHP Version: 7.4.15
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
I do not understand why you would need to add the PHP versions
there. A part of the mutex name is the "system" hash, which also
includes the PHP version (in case of -dev versions even the
timestamp of the build). Is there possibly a hash collision? You
can check the names of the mutexes with Process Explorer[1];
select the PHP process, and press CTRL+H. The mutex name should
begin with ZendOPcache.SharedMemoryMutex@.
[1] <https://docs.microsoft.com/de-de/sysinternals/downloads/process-explorer>
Previous Comments:
------------------------------------------------------------------------
[2021-03-02 15:05:42] aschmidt at anamera dot net
Two closing comments:
a) Here's my working cache_id setting which will also cover CLI environments (where an AppPool
ID doesn't exist), and further making it unique per PHP version to avoid the possibility of
version clashes:
opcache.cache_id="v"PHP_MAJOR_VERSION""PHP_MINOR_VERSION"_${APP_POOL_ID}"
b) Please do note that the necessity of the above disproves the assertion/assumption that in my
scenario there should not have been any Mutex problems in the first place.
------------------------------------------------------------------------
[2021-03-02 11:47:32] cmb@php.net
Oh, I was not aware that app pool specific enviroments are only
supported as of IIS 10. But your suggestion to use APP_POOL_ID
for this purpose is great, so I've documented that[1].
Do you still want to have the changeability of opcache.cache_id
changed to PHP_INI_PERDIR, or can this request be closed?
[1] <https://github.com/php/doc-en/commit/7c6c83d08e97007ca75f739873f8125c6c0640cf>
------------------------------------------------------------------------
[2021-03-02 11:26:24] cmb@php.net
The following pull request has been associated:
Patch Name: Print error code if CreateMutex() fails
On GitHub: https://github.com/php/php-src/pull/6745
Patch: https://github.com/php/php-src/pull/6745.patch
------------------------------------------------------------------------
[2021-03-01 22:07:11] aschmidt at anamera dot net
That's a helpful suggestion. The tricky part is that Windows sets Environment Variables
"per User", which is the same for all sites in my scenario. With IIS 10 there's an
option that will support setting "per Pool" Environment Variables.
However, even in prior IIS versions, the Application Pool Name itself is available as an environment
variable, so one can use:
opcache.cache_id=v74_${APP_POOL_ID}
I've activated the above and initial tests have not yet caused any Mutex errors.
------------------------------------------------------------------------
[2021-03-01 14:14:17] cmb@php.net
> Yes, the mutex log entry is not helpful at all.
Yes, that should be fixed.
> Can you please clarify if your suggestion is to assign an entire
> unique PHP.ini via environment variable.
That can be an option, but my idea was more like using the
environment variable in php.ini, e.g.
opcache.cache_id=${OPCACHE_ID}
Would that work for you?
Changing to PHP_INI_PERDIR might generally make sense, though, but
it appears that would be the only OPcache setting with that
changeability.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=80812
--
Edit this bug report at https://bugs.php.net/bug.php?id=80812&edit=1