Edit report at https://bugs.php.net/bug.php?id=76280&edit=1
ID: 76280
Updated by: cmb@php.net
Reported by: teo8976 at gmail dot com
Summary: Performance degrades permantly when overwriting PHP
files, until apache restart
-Status: Open
+Status: Feedback
Type: Bug
Package: opcache
Operating System: debian
PHP Version: 5.6.36
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Is this still an issue with any of the actively supported PHP
versions[1]?
If so: if updated files are being cached by OPcache, the old files
will never be removed from the shared memory (this is reporteded
as wasted memory). This wasted memory may sum up to the point
where you no longer have sufficient free memory, so no more files
can be cached, what would cause them to be executed uncached.
That might explain the behavior you've described.
[1] <https://www.php.net/supported-versions.php>
Previous Comments:
------------------------------------------------------------------------
[2018-04-28 15:27:04] teo8976 at gmail dot com
> the most lkiley problem is that your configuration don't suite your workload
Let's assume this is the case.
That would explain a TEMPORARY degradation in performance.
Even if that is justified by a bad configuration which is my fault, if that doesn't recover on
its own after a while that no file is being changed, then there's a bug.
> pretty clear says you never gave a damn about your configs
Indeed, I never did. But again, if I need to worry about fine-tuning my configs just for PHP to be
stable, then it's ill-designed.
------------------------------------------------------------------------
[2018-04-28 15:20:08] spam2 at rhsoft dot net
the problem is pretty sure that your "opcache.memory_consumption" setting is too low and
you are trahsing opcache with a lot of changes - so either increase you config or reload the
webserver after chaning lot of files
the most lkiley problem is that your configuration don't suite your workload and since you even
don't know how to look pretty clear says you never gave a damn about your configs
------------------------------------------------------------------------
[2018-04-28 15:13:39] teo8976 at gmail dot com
> nosense - following your logic running a server without
> opcache would be insecure at all
No, that is not following my logic. I meant something that can cause a SUDDEN crash of a website
just because you do something as trivial as upload some files. I thought "security
support" implicitly covered fixes for bugs so serious as to cause a system to go completely
down triggered by trivial events.
I know *strictly speaking* this is not security related, but I thought in the context of support
version lifecycle "security" was short for "is secure and at least barely
usable".
------------------------------------------------------------------------
[2018-04-28 15:00:01] spam2 at rhsoft dot net
>> Please check whether the deployment
>> of new files triggered an opcache restart
>>
> How can I check that?
look at the opcache vars and in doubt feed "opcache status panel" into Google and ask
yourself why you don't have such tool installed - not knowing what a server does would i
personally call a security issue (and no such a panel out-of-the-box is no good idea because *that*
would be a security issue)
> Something that can cause a website to go down
> permanently because of a performance degradation
> with no good reason, I would call a security issue
nosense - following your logic running a server without opcache would be insecure at all
------------------------------------------------------------------------
[2018-04-28 14:54:14] teo8976 at gmail dot com
> Please check whether the deployment
> of new files triggered an opcache restart
How can I check that?
> Generally any slowdown should only be temporary though
It isn't. When this happens, the slowdown is permanent until I restart apache.
In the screenshot I attached (where I unintentionally cut off the part that showed the times), it
went on for several hours. It was also surprisingly "stable", everything being
consistently X% slower (of course it is possible that the slowdown was affecting a specific piece of
code being called by all scripts)
> In any case, PHP 5 is no longer supported
http://php.net/supported-versions.php says
"security support until 31 december" this year. Something that can cause a website to go
down permanently because of a performance degradation with no good reason, I would call a security
issue.
------------------------------------------------------------------------
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=76280
--
Edit this bug report at https://bugs.php.net/bug.php?id=76280&edit=1