We have a server at my work with APC installed on it, and about every 1-2 weeks, all of a sudden this error just starts being thrown and when it is throw it happens a lot. It will be perfectly fine for the whole of the 1-2 weeks, and then it just blows up. The only thing I've figured out to do to stop the errors is to restart apache. The website seems to work fine while this is happening, but I am worried that if I don't restart apache the server it will eventually start to become unstable and start behaving erratically.
When I search for this on Google I found one page that was sort of useful (a PECL bug), and a bunch of pages that were indexed while they were having this error.
I would love to solve this warning or at least figure out more about what the problem is. Thanks for your time!
P.S. The server hosts a few sites and a couple of those sites are using expression engine. Other than that it is pretty much your normal LAMP setup.
Related
I've been experiencing an odd issue where something is getting cached somewhere and I'm not sure which item to blame and it's not only driving me nuts, but slows down my development workflow (and is VERY confusing).
The Problem: I save changes made to a PHP file and refresh my browser, however the changes do not show up.
Expected Behavior: The refreshed browser shows the updated file.
Actual Behavior: The most recent changes do not show up.
For some background, here are the possible factors that could be contributing to this problem:
Macbook Pro (16-inch, 2019, 2.6 GHz 6-Core Intel Core i7)
Mac OS (Monterey v12.5)
Chrome (v104.0.5112.79)
MAMP Pro (6.6 Build 33836), Apache (2.4.46), PHP (7.4.21), MySQL (5.7.34)
Xdebug
PhpStorm (2022.2 Build #PS-222.3345.135)
Gulp (v4.0.2) - Unlikely
BrowserSync (v2.26.14) - Unlikely
I work with WordPress although I don't think that's a factor here. Basically what is happening is I'll go to make a change to a PHP file, which could be just adding more code, fixing an error, or maybe even doing a var_dump, and when BrowserSync refreshes, the changes are not reflected, so the new code does nothing, or the error still exists, or the var_dump doesn't show up. Another example is once var_dump does work, if I go to remove that debugging line, it will still show up.
I haven't figured out a fix either, other than just repeatedly refreshing the browser or re-saving the file (sometimes after adding a few blank lines to "trick" whatever it is causing it to think the file has not been changed). This can happen with or without running Gulp/BrowserSync, but I don't want to rule this out as a potential part of the problem. It's behaving like the file has not been saved.
I sometimes will quit gulp and restart to see if that resolves the issue, although it's hard to tell if it has any effect since the problem persists for maybe 30 seconds and then I'm able to see the updated file.
This is something that has recently started to happen but doesn't happen consistently. Sometimes everything works as expected, but it's hard to tell what factors are contributing to when the issue starts happening again. Most recently it started again after I restarted PhpStorm (to apply an update).
Has anyone else experienced something like this? I'm not even sure what other information would be helpful, but would be happy to post more details if I'm missing something. Thanks!
When I started developing with Symfony on Windows it worked pretty well at first, but lately the profiler is taking way too long to load the toolbar.
The profiler is taking 18.48 seconds to load (day:116).
I didn't find anything helpful online, does anyone know what might be causing this?
Ok, this is super weird, but after I did a JSON request (that returns a JsonResponse) everything turned back to normal. I have no idea why this had an effect at all, since this problem persisted over hours and server restarts did nothing. Anyway, I hope this might help someone else in the future.
Edit: The problem returned after a while, and there didn't seem to be any fix. I was using XAMPP on Windows 10 with Xdebug, APCu and OPcache. My hardware was definitely not the problem, I was running the server on a really beefy machine.
Kind of fix for people with the same problem:
I started using a Ubuntu VM, and it never happens there, even though I use the exact same code and server setup aside from the OS.
We're currently banging our heads against the wall with our Azure setup. It might be us who lack skills, but we cannot figure out how to run our instances more smoothly. We run PHP 5.6 w. wincache on Azure. We have multiple instances, which share most of the files. However, it appears that the PHP cache is not shared, and some times when we deploy some files will magically be corrupt. For example a syntax error in a file which should not have a syntax error. This results in our platform throwing up, because, well syntax error in a file.
The only way to fix this appears to be a hard restart of our services, which takes time both in terms of the restart and warming the cache. We are trying to move away from the PHP setup, but unfortunately it's what we have currently.
Is there anyway to flush the system or specific instances without having to restart everything? It's kind of a ball toss if our release goes well or has loads of issues, which in turn makes us more hesitant to release.
I've recently switched my web server to Centos 6.3, with apache 2.2.15, PHP 5.4.11 and APC 3.1.14.
I started receiving complaints from customers from time to time, that a page is not working, or strange errors appear. I saw that the affected pages have question marks and other strange symbols in random places in the output, even though the sources are OK. When I change a single letter in the source file, the page starts working fine.
I suspect APC, but I cannot find any clue when and why this happens.
I use mercurial to push changes to production, but I've used this approach for years with no problem. Maybe something in the configuration is new now, but sadly I don't keep my old configuration.
Below is a screenshot from the last corruption.
Edit: Here's the response after I've changed a single character in the source, saved it, and then undo the files (same is if I just restart the web server or clear APC opcode cache):
Notice the line numbers didn't match, but it's 100% the same request, so the response should be the same also. The line 111 from the first screenshot should not be there at all. It seems that it's from another source file...
I've changed apc.stat_ctime to 1
Verification with ctime will avoid problems caused by programs such as svn or rsync by making sure inodes haven't changed since the last stat. APC will normally only check mtime.
I'll be watching closely on the problem, because it's occurring once or twice a week and post here if this fixed it.
The problem is when I open any Magento page in browser, including /admin, it doesn't load properly and keeps loading forever. No files where changed - yesterday it was working, today it stopped working.
Can anyone recommend how to debug it? And what might be the reason for this?
There are no any errors in logs, php works fine, we tried rebooting server.
Thank you.
there wont be any errors unless you have low server resources, or maybe you have some content from external servers that probably down right now. first quick debug - open page in chrome and inspect element, you will see what slows your page. or you can check top, no IO problems, enough RAM, no processes running with >100% CPU?
rebooting server never fixes your problems. check if you have cache enabled.
not much information here to tell you exactly whats going on.
I recently ran into this problem too. My Magneto 2 site (on Ubuntu 16.04) worked fine one day and then would continuously load the next. Cleaning the cache and deleting/rebuilding static files made it work briefly, but it would go back to not loading the pages within a few clicks... even the admin.
My fix happened to be that the disk was full. I didn't realize it until I went in command line and updated composer which kept giving me a disk full error.
I switched to the desktop on Ubuntu and ran a disk analyzer, which pinpointed exactly where all my space was being used.
gksudo baobab
I didn't have gksu installed, so I had to install it first by typing:
sudo apt install gksu
It turns out I had backups that had not been deleted. Large tar files that I no longer needed.
I hope this helps!
Edited to include which OS I am using.