Commit d2cb8a7
committed
feat(settings): simplify OPcache checks
For the overall OPcache size check, we currently compare used memory with free memory only. However, `opcache.memory_consumption` is split into `used_memory`, `free_memory` and `wasted_memory`. When cached files change on disk, old entires are not replaced or removed, but remain as wasted memory, until their percentage reach `opcache.max_wasted_percentage`, and if the cache is actually full. When this happens, the engine is restarted, resetting the cache completely, like a `opcache_reset()` call.
As long as we do not consider wasted cache, recommendations based on free memory can be false. The probably most accurate check would be to count wasted memory as free nemory, if it is above `opcache.max_wasted_percentage`, as the engine will be restarted as soon as needed, freeing up this space as minimum. On the other hand, wasted memory below the threshold can permanently block the OPcache, which supports counting it as used memory. Depending on the situation, it could be also advised to reduce `opcache.max_wasted_percentage` instead. But too frequent cache resets break its purpose as well.
The matter is IMO too complex to consider everything in detail. But what we know for sure is: if the cache is full (`$status['cache_full'] === true`), and the limit for cached keys has not been reached, the OPcache was too small to maintain free space, with wasted memory below the threshold, where it consumes memory permanently. Recommending to raise the OPcache size in this case, is hence as accurate as it gets.
`cache_full` can be true as well if the limit for cached keys has been reached, hence we need to merge both checks. In this case `num_cached_keys` equals `max_cached_keys` exactly, hence it is easy to differenciate whether `opcache.max_accelerated_files` or `opcache.memory_consumption` needs to be raised.
In practice, the change relaxes the checks: the respective limit needs to be reached 100% instead of 90%, to trigger a warning, eliminating also false alarms if a large share of the cache is consumed by wasted memory, which would be automatically freed when cache is 100% full.
Additionally, the recommendation for raising `opcache.max_accelerated_files` now says "a value higher than `max_cached_keys`", instead of `opcache.max_accelerated_files`. The actual limit, reflected by `max_cached_keys` from status, is a next higher value from a set of prime numbers. E.g. if `opcache.max_accelerated_files` is set to 10,000 (PHP default), the effective limit is 16,229. Recommending "higher than 10000" could hence lead to a settings change without effect. To be sure the effective limit is really reached, it needs to be "higher than 16229" instead.
Signed-off-by: MichaIng <[email protected]>1 parent eb9a621 commit d2cb8a7
1 file changed
+12
-14
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
57 | 57 | | |
58 | 58 | | |
59 | 59 | | |
60 | | - | |
| 60 | + | |
61 | 61 | | |
62 | 62 | | |
63 | 63 | | |
| |||
70 | 70 | | |
71 | 71 | | |
72 | 72 | | |
73 | | - | |
74 | | - | |
75 | | - | |
76 | | - | |
77 | | - | |
78 | | - | |
79 | | - | |
80 | | - | |
81 | | - | |
82 | | - | |
83 | | - | |
84 | | - | |
85 | | - | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
| 80 | + | |
| 81 | + | |
| 82 | + | |
86 | 83 | | |
87 | 84 | | |
| 85 | + | |
88 | 86 | | |
89 | 87 | | |
90 | 88 | | |
| |||
0 commit comments