3rd Party Plugin Compatibility: MainWP WordPress Management Plugin #629
Comments
|
I will further try to tie this down. I have deliberately taken one site on this server off ZenCache Pro and subsequent updates to that site have not taken it down. On the other sites, the updates do take place, and MainWP reports all updates are successful. But the sites have gone down. It has to be something to do with the handshake process that MainWP uses, connecting the child to the master. One might suspect that ZenCache Pro is detecting the update (as a result of something that the child is doing?) and flushing the cache, and must be doing so at a time when the MainWP child is using a critical resource. |
|
OK. Spent an hour or so this afternoon. Also upgraded my server to PHP5.6.16 to see if that made any difference. The surest way to crash random sites (assuming they all have ZC Pro installed, activated and cache enabled), in MainWP plugins panel do a search on all domains for any active plugins containing the string 'zen'. Random sites will crash (never all, rarely none), requiring a http restart. If the ZC Pro plugin is active, but the cache off, the same search will cause no problems. All cache options (when the cache is active) are at default (except the include test string). |
|
@CotswoldPhoto I noticed that you're running PHP 5.6; these issues are possibly related to #630 and #624. |
|
OK, following suggestions on those and linked threads, I tried the following:
My conclusion is that Zend OpCache is running out of memory. Now, this is a Server related issue. Luckily, I have a dedicated server and I manage it and footling around in Linux is not an issue for me, but, for others .... My guess is that OpCache has a bug, which by me throwing resources at it gets around it. Bear in mind that I am on the latest release of PHP5.6 (5.6.16), that suggests that this bug still persists, maybe even into PHP7.0. Trevor |
@CotswoldPhoto Woohoo! Thank you SO much for testing that and reporting what you've found. cc @jaswsinc |
|
@CotswoldPhoto Just to confirm: When you say "Fixed" are you referring to the Error 500 going away, or the issues with MainWP going away, or both? |
|
Both. |
|
Looking at the apache error log, it was reporting the same corruption error as other reports (not related to MainWP or ZenCache), ie zend_mm_heap corrupted. When you look at the bug reports for PHP5.5 through to PHP7, only PHP5.6 has this problem with Zend OpCache, with zero reports in PHP5.5 or PHP7 (clearly the PHP7 reports will mainly using the betas and Release Candidates, as the final release was only on December 3). |
|
This morning it is back. Not sure if that is because the resources I gave it were used up, so I restarted the server and tried again, and 3 of my sites immediately gave 500's. I have now set my php.ini as follows: opcache.memory_consumption=1024 # was 256, then up to 512, now up to 1024 So far no crashes. Early days. The same error in apache log (zend_mm_heap corrupted). |
|
@CotswoldPhoto Thanks for the follow-ups. Interesting! I think you're right about there being a bug in Opcache. 1024 seems very high; i.e., like you have a memory leak somewhere. I can't imagine a site powered by WordPress requiring any more than about 128MB of RAM. 256 should be more than enough. That's memory for PHP scripts (i.e., the scripts themselves), nothing more. So unless you are using Opcache for something more (not likely), then I'd say 1024 is unnecessary; i.e., for you to need that much RAM there must be a leak somewhere.
Be sure to also set Just in case you have a rogue script somewhere in the site, you might also want to have a look at this setting, which would help you guard against a huge PHP file trying to eat up all of your RAM. See: http://php.net/manual/en/opcache.configuration.php#ini.opcache.max-file-size
Agree. I haven't seen this behavior in PHP 7 myself, but you could be right. In either case, if I were you I'd strongly consider either an upgrade to PHP 7 or a downgrade back to PHP 5.5. Just to see if that will correct this problem for you. At the moment, it seems like your best chance of success. |
|
@CotswoldPhoto A tool like this is quick and easy, and it might assist you in diagnosing the problem. See: https://github.com/rlerdorf/opcache-status Or, you can just put together a PHP script and output the array and review. <?php print_r(opcache_get_status()); ?> |
|
OK. I had tried that tool already and it showed me nothing. I have re-set the opcache settings as follows: opcache.memory_consumption=256 So far all is OK. I will probably migrate to PHP7 when cPanel release 54 is out and gets to the 'current' tier, in a month or two. |
|
What I CAN see is that by making these changes: OpCache has used up almost all of the 256M straight away. I am thinking that by limiting the filesize to 100K, I have stopped it loading any large files, hence the drop in hit rate, but freeing up the cache from these large files has let the small ones in and they must be the critical ones to loading WordPress fast. We shall see if this works. It is shame that Zend have not (better) explained all the OpCache settings, but as time goes by bloggers are doing this for them. |
|
I can confirm that the problem is back. I am going to push the memory back up for now. |
|
I have to confirm that only when I have increased the settings like this: opcache.memory_consumption=1024 It NOW seems 'stable'. I was 'lucky' in that WooCommerce just released an update. I ran it on one site at a time from MainWP, and each time the update crashed at least one site (not the one that was updated!!). It was only when the settings were as above did it all go OK. BTW, given 1024MB to play with, OpCache seems only to want under 400MB, but the hit rate is up to 80-90% now. Probably means I could increase the max file size safely. |
|
@CotswoldPhoto A new version of ZenCache was just released that includes many bug fixes and enhancements. You might want to give this release candidate a try to see if it addresses any of the issues you were having here. See http://zencache.com/zencache-pro-v151216-rc-release-candidate/ |
|
I can confirm that this RC fixes the problem, although I AM having some issues, and these I have reported on another ticket. |
|
@CotswoldPhoto Awesome! Thank you for confirming. |
|
Sad to say, but it is doing it again :-( |
|
@CotswoldPhoto Sorry to hear that. :( It sounds like this may be more of a compatibility issue between ZenCache and MainWP. Am I correct to assume that you've only been seeing these issues while using MainWP? |
|
What I HAVE done that DOES seem to avoid the issue, is to install a WordPress OPCache plugin: https://wordpress.org/plugins/opcache/ And running its Reset function before the update has NO effect on the cache, as though the OPCache has somehow become locked. Running it immediately after the update has the desired effect of flushing the cache and then Apache does not crash. It is as though ZenCache has somehow grabbed the communication channel to the OPCache and locked it, rather like locking a record on a database. |
|
Well, I thought that had worked, but it does not. Roll on PHP7 support for my server stack. |
|
@CotswoldPhoto This definitely sounds like a bug in OPcache and your best bet for now (until you upgrade to PHP7) is probably to disable OPcache altogether. Since you're running WordPress, ZenCache is going to give you more bang-for-your-buck than OPcache when it comes to speeding up your site(s). We haven't any any reports like this with PHP 5.5 + OPcache, however there have been a couple of similar reports with PHP 5.6 + OPcache, so it sounds to me like there's something buggy with OPcache in PHP 5.6. (We went through a similar issue as this with PHP 5.3 and PHP 5.4 when running the APC extension, which we discovered is a lot more buggy than OPcache.) If you're running PHP as a module in Apache, you should be able to add this to your Or if it's running as a CGI/FastCGI, you can add this to a |
|
I can disable it by editing php.ini and stop the module loading. Easier to do that than to edit the .htaccess in every domain. Thanks for all your help. |
raamdev
modified the milestones:
Next Release (Pro); 1st CC Notice,
Future Release (Pro)
Cannot reproduce bugMainWP Dashboard Site
Child MainWP Site
Steps taken
|
|
@renzms Did you test updating Comet Cache Pro via MainWP? |
|
For me, the last update (and none before that either) did not appear in the updates panel dashboard in MainWP. They only showed up when you visited the individual sites own admin. |
|
So, minutes after I post that, up pops a notification in MainWP that a RC version is available on my dev site. Cool. Guess that's sorted then. |
Yup! 😄 Was able to update Comet Cache Pro 160917 to the latest Comet Cache Pro 161116-RC via MainWP. Tested two ways:
|
|
@CotswoldPhoto writes...
@renzms writes...
Great! It sounds to me like this issue has been resolved then. I'm going to mark this issue as closed for now, but if anyone discovers a problem here again I can reopen it. |
This GitHub issue exists to research compatibility with MainWP, a WordPress Management Plugin that provides a Dashboard Server/Client allowing you to manage several WordPress sites from a central site.
The following issue with ZenCache Pro was reported (ZenCache Lite, as of v151107, seems unaffected):
Referencing (internal) ticket: https://websharks.zendesk.com/agent/tickets/9798
The text was updated successfully, but these errors were encountered: