Re: OPCache: invalidate vs unlink
| From: | Nikita Popov | Date: | Sun, 21 Jan 2018 12:04:49 +0000 |
| Subject: | Re: OPCache: invalidate vs unlink | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-101646@lists.php.net to get a copy of this message | ||
On Sun, Jan 21, 2018 at 11:00 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
>
zend_accel_invalidate is exposed to userland as
> opcache_invalidate
> and marks a script as wasted, however, it does not remove that script
> from the OPCache.
>
> There is also the zend_accel_hash_unlink that actually does
> that, it's
> there since the beginning of time but without a single call to it in the
> entire codebase. It actually removes a script from OPCache, yielding the
> desired result of freeing up some space without requiring a complete
> restart of OPCache.
>
> What are the reasons that this function is not used and not exposed?
> What side-effects does it have if we actually selectively remove scripts
> from OPCache?
>
> We replaced the zend_accel_invalidate call with
> zend_accel_hash_unlink in the
> opcache_invalidate implementation and
> it worked flawlessly. However, it could be that there are some things
> that we are simply overlooking.
>
Unless you are running specifically into the max files limit (and not the
memory limit), unlinking from the hashtable will not provide any benefit.
It does exactly what it says on the tin, and in particular it's not going
to free up any space.
The reason why opcache has a restart mechanism, is that it does not track
which files are currently (potentially) in use. During a restart it waits
until all workers stop using SHM, at which point the memory can be safely
reset. To improve this some more precise tracking of SHM usage would be
necessary (not necessarily per-file, but more than just "yes or no").
Nikita