I have just installed Wordpress in a new Azure Web Application and everything is running fine at the moment.
However, I am getting notifications that I am exceeding the storage file system quota (1GB).
I went to check the value on the Azure Portal and the strange thing is that the storage usage is varying from 12% to 100% every single minute! Somehow the measurement must be crazy, since I am not changing a bit in my website nor have huge files there.
12% must be the realistic value for Wordpress. I have tried to reset the website and check log files to see if there is anything wrong, but did not find anything.
How can I fix that?
Igor.
You might want to try de-activating the most recent plugins you installed 1 by 1 to see if this corrects the issue. There could be a bug in one of them that has some type of loop that generates a large log file.
At the end of the same day the problem disappeared. It seems everything is stable now, but if happened once, it might happen again. I will keep you posted in case I experience this problem again.
Thank you.
Related
I've checked for possible duplicate and found one, but having implemented his solution and not finding any luck, thought I'd ask the experts.
Crashlytics has been setup on my app properly. But it isn't reporting the errors in my dashboard. I've attached a picture from my terminal. The crash is being handled and an attempt is made to send it to the dashboard.
Perhaps there is a delay from the time I setup crashlytics for the first time? It has been up and running for at least 30 minutes. And I've also downloaded the google-services-json file again after setting it up.
Any suggestions?
Everything is fine. There was just a delay in the reporting. The crashes have started showing up now, but they aren't as instant as I thought they would be. Much more detailed than Google Developers crash report though.
I have a Azure App Service app that I'm trying to get deployed.
Today I ran into an issue where .NET informed me (via the yellow screen of death when I browse to the URL of my app) that I had a missing DLL (for the purposes of this question I don't think it really matters).
I used FileZilla to publish my changes in an attempt to do a manual deployment first and then work my way to automate it.
After so many attempts to fix it I later realized that the error message never changed. I did something more severe and renamed my bin folder into something completely different and the exact same error message would appear.
I've stopped the service, restarted it, and as mentioned, renamed folders, etc. and still the exact same error message persisted.
I also decided to open up the Azure Portal Console for my App Service app to browse a bit and to my amazement, nothing seemed to have reflected at all. The FTP shows one thing and the Console shows another.
Would anyone have any idea as to why this is happening?
I eventually got it to work and I will share what I tried.
I deleted the web app and created it again (I found this to be important the first time around). This was quite time consuming and did help but it wasn't long before the same problem happened again.
Then I finally found a solution that seems to give me consistent results:
I kept on editing the Web.config which seems to force a recompile and clear some sort of cache. So each time the web app stopped updating, I would make a slight change in the Web.config, upload it via FTP and the app finally updates.
If anyone has any more details on this, it would be greatly appreciated.
I've found plenty of versions of this questions, but neither seem to go further than an apparent Google Chrome bug.
What happens is that whenever I copy a codeigniter setup to a new folder on my server, to start a new project based on it, I get "no data received" in any browser I try it on.
The strange part is that the problem is solved if I go into each file that gets include()-d, add or change something irrelevant (like a blank space) and save the file. I don't know why, but this makes that specific include() work. Otherwise, the script stops before it.
There's nothing logged in the server's access or error logs so I can't figure out what the problem might be.
Needless to say this has been driving me crazy. Any suggestions?
Thanks!
My sysadmin figured it out. It was related to system wide APC cache. I used apc_clear_cache() at the top of index.php and everything works like a charm!
I'm having a problem creating a package for a web role that totals up to 380 megabytes on disk. I can get CSPack to run fine when specifying the /copyOnly flag, but as soon as I try to create the actual package file I get an OutOfMemoryException. The problem started after I added around 350 megabytes of static content to the web role project.
I've already found a similar question here on Stack Overflow, but even with all the content set to "Do Not Copy," I still get the same issue with CSPack crashing. Just to verify that the static content is what is causing an issue, I excluded it from my project in Visual Studio and CSPack ran fine from the command line.
Here's the command I'm executing from cmd.exe:
"C:\Program Files\Windows Azure SDK\v1.4\bin\cspack"
BizBlimp.Azure\ServiceDefinition.csdef /role:BizBlimp;Build\BizBlimp
/role:BizBlimp.QueueWorker;Build\BizBlimp.QueueWorker;Biz
Blimp.QueueWorker.dll /sites:BizBlimp;Web;Build\BizBlimp /rolePropertiesFile:Biz
Blimp;properties.txt /rolePropertiesFile:BizBlimp.QueueWorker;properties.txt /ou
t:Build\BizBlimp.Azure.cpkg
And here's my project file for my web role: https://gist.github.com/88e776bb611cf6a8521e
I've been banging my head up against this problem for the last couple work days, so any help would be greatly appreciated.
Edit: Link to the same issue on the Microsoft Azure Forums. Looks like this is gaining some attention from an MSFT employee.
That is quite a lot of static content. Every time you update your application you'll have to upload that 350mb of stuff. Have you considered storing the static content in blob storage? It looks like most of it is images and would sit quite nicely there. I'm sorry this doesn't solve your crash issue, but it will probably make your life easier in the long run.
Everything works fine for most accounts 100% of the time but here and there some users who are able to access a subsite fine one day are greeted with a standard 404 the next. This can last for an hour or two days, it's really inconsistent.
I check the iis logs and it says the status is also a 404 for these requests, nothing else looks unusual. Sharepoint logs have nothing for the timestamps either.
Correct me if I am wrong but if it was a permission issue an access denied message would be shown.
It is not the individual computer because when a user is having this problem and I can log in with their account and I also get the 404 error although I am on the exact site with another account in another browser at exactly the same time, and it works perfect.
Any suggestions would be greatly appreciated, I've done a fair amount of searching but can not find a similar situation or help anywhere.
Since the information is very strict at the moment, I will throw a few questions that might lead you towards the problem.
Are we on a loading balance setup? The intermittent 404 might be cause by one of the servers Web FrontEnds not correctly serving requests.
Are we running out of disk space in the SQL Server machine? This might cause it
Are the blogcache or site caches enabled? Some routines may break them
Do we have Anti-Virus on the server? (it HAS to be asked :p)
We get very high packet loss between the servers? (The error would be different though)
Something that might occur very often is when you have, say, custom code a DLL on the GAC or the bin folder, and since you could be on loading balance the second server does not have this DLL in its own GAC or BIN folder. Sharepoint usually raises 404s when assemblies are not found too, not only requests.
This seems like a longshot, but... could those SharePoint sites be throwing a 404 HttpException? It seems like you'd see that in the SharePoint logs, too, so it's even more unlikely.
At any rate, is your SharePoint logging level set to an appropriately verbose level to debug weird stuff like this?
Are people checking in & publishing master page changes when new CSS files and/or other includes (script files, etc.) are not yet published at all? I've seen this cause a 404 a few times when users forget to check before they publish.
I have had to write custom code within a SharePoint context and I had those 404 errors as well. The solution, in my case, was to ensure that the block of code executing had these 2 conditions met:
1) Run with elevated privileges, regardless of the fact that it is a 404 this was part of the solution.
2) web.AllowUnsafeUpdates = true; This line of code needed to be added even though it was wrapped within an elevated privileges block.
Once these were added the issue did not occur. This was happening on both load and non-load balanced environments.
This reminds me of a strange asp.net bug that I had a few months back.
It was caused by a patch that had been applied (to the framework if I remember correctly)
try downloading this Windows update list tool and have a look at what has changed since the problem started.
I concede that if there was a problem with a patch then its more likely that it would be a consistent error, but it's worth a look.
It was a permission issue, I had figured this out awhile back but basically a few accounts were not setup properly and could not load a fresh copy of the page, when someone else would hit it they would be able to view the cached page fine. Error was never thrown as a permission issue or access denied anywhere but this is what fixed the problem.