We had IIS 6 on Win 2003, We upgraded to Win 2008 and now our app is same, basically its a simple file server to resize images and cache them and deliver to clients. Since resizing requires more memory size, running under Pipelined Pool causes no more memory errors so we went back to Classic mode and there is no ther website, only one and we are happy with it.
Today morning I saw the website was down, and I went and checked CPU Usage of server, it displayed 100% CPU usage by w3wp.exe, now we never had this problem before, the code is same that we did use in old IIS 6 and its simple Database read and Response.Write..
Restarting server solved the issue, but if I get same problem again, how can I check which part of code of our website did use such a huge cpu usage where else there is absolutely no error log and no event viewer error as well.
The code that is used in website is hardly few lines, typical DAL query to database and response.write thats all. Files are stored in blobs in database but that has nothing to do with anything because it did run successfully for 3 years with same SQL Server. The only change is IIS 7 and its Classic Application pool against IIS 6 with default app pool.
I would appriciate any tool or anyway to atleast monitor what caused this problem. We have Win 2008 running since last 30 days and we only got this error once.
In our cases, since we have 4 processors, we then increased the "number of worker process to 4" currently working well so far as compare before.
here a snapshot: http://pic.gd/c3661a
Related
I have several legacy applications built originally on asp.net 2.0, IIS 6 and update panels. They were working fine on that old server, response time was never more than 4 seconds.
I moved them to a new windows 2008 server with IIS 7.5 and performance is much slower at 20 seconds per async request/response.
The code has not changed
Database has not changed.
The appPool is running in classic mode.
The database responds immediately once it receives the query (again
it takes 20 seconds for the database to receive the query)
I have installed the latest AJAXControlToolkit for ASP.net 4.5.
I did some analysis and found that the request is what is taking so long but I don't know why. I have tried switching to integrated mode but that had no positive effect.
Any ideas on what I can do?
Thanks, Justin.
Seems like a network issue to me.
Database has not changed.
Database has not changed and you've moved the code to a new server. Are you accessing the DB through a local IP? If not, you need to do that.
Verify the connection speed by pinging the old DB server from your new server and see if it is taking a long time to get a reply.
The database responds immediately once it receives the query (again it takes 20 seconds for the database to receive the query)
If the database is quick in responding and it was working fine earlier, there is no chance that there is any problem with it. Something is fishy in data transmission over the network.
Just in case, it is not a network problem:
1) Please clean and rebuild the solution and upload it again. Deleting all the "bin" folders in every project and rebuilding them again worked for me. It was the reason behind my problem.
2) Please make sure that you are using the latest builds of DB connectors just in case you are using MySql or Oracle.
3) You may want to use fiddler to trace your http requests and see where exactly the problem is.
I have an application that runs perfectly fine locally using the VS 2010 application server, however, when I deploy to our web app machine startup just spins and spins and never loads. We have other apps on this same machine that load just fine (this is a debug deployment of same app in product).
I have been spinning my wheels on this for days and I am at a loss as the problem could be.
Here is what I did
Create a new directory (same level as other apps)
Copied over our existing test (www.domain/test/) and it works fine
Build and publish new debug app (www.domain/test/) and it just spins trying to load first form.
I know the diretory is "working" as the 'test' application I put there works fine.
If it's killing the App pool, you might get something in the event log. Fiddler (www.fiddlertool.com) is great http debug tool which let you see if you're in a redirect loop. Also Firefox shows a more meaningful error, something about exceeding the max redirect count.
It does sound like something is looping, but not quick enough to cause a stack overflow, which is odd, because you'd expect it to fail every time.
Simon
Do you have the ability to remote desktop into the machine? If so try running process explorer and look at the process details for the worker process that is giving you issues. Definitely look at the TCP connections being created. If your processor is pegged at 100%, and memory usage is rising then you probably have an endless loop running.
It sounds like it's more related to IIS than ASP.NET. What about the identity that the website is running under? Is it possible that the user the site's running under a bad user, or maybe the password needs to be re-entered?
I did a quick Bing search
There are a lot of postings regarding the error message you described above. Most if not all point to code in your app that is crashing. I know I had a similar problem when I used an automated/threaded daemon utility in my web application. Make sure your code is not bringing down the server, sometimes the VS2010 web server is a little more foregiving than an actual IIS deployment.
If that doesn't work try running a Remote Debugging Session to try and catch any errors being thrown but not handled.
Lastly you could try to setup a new local IIS server to see if you have the same problems. Scott Gu has a nice article about using IIS Express to do this.
Every few hours, My MySQL database (running 5.1) seems to hang and viewing the processlist shows dozens of processes running "SHOW VARIABLES". They finish instantly only to be replaced my more of these processes. After a few minutes, everything disappears and goes back to normal.
I'm using the .Net Connector and the web application is on IIS 6. Has anyone ever seen this before?
I know there were a couple similar questions, but none solved my problem.
This issue just started within the last couple of days. I don't always hit VS everyday, so I can't say for sure when it began.
When I start debugging, the app loads in IE, but the w3wp process dies with the message
"The program '[9252] w3wp.exe:
Managed' has exited with code 0
(0x0)."
I'm running Vista and debugging on IIS 7 (local machine). VS 2005. This is not a new environment. Everything had worked for months before this issue began.
I've Googled and found a number of solutions. I tried messing with the Process Model settings in the app pool. I tried changing the app pool. I've dug through all the settings of VS I could find that seemed applicable. I am running as administrator. Also, I run VS 2008 as well, and that is working fine.
Update: I tested another app and also had a problem. Though that app was configured to debug on the native VS web server (I forget what it's called off the top of my head), so the error is
The program [7192]
'WebDev.WebServer.EXE: Managed' has
exited with code 0 (0x0).
After about 8 hours of wasted time, I can answer my own question. It's an issue with VS2005/IE8. They, for whatever reason, do not play nice together. I uninstalled IE8 and everything is working fine.
I know Microsoft is a big company, but some interdepartmental communication and testing would be awesome.
I was having this same problem.
According to this Microsoft list of Visual Studio 2005 issues on Microsoft Vista, there are two requirements to fix this issue:
Start Visual Studio with Elevated Administrator Permissions
Make sure that the IIS 6 Compatibility Layer for IIS 7 is installed
The IIS 6 Compatibility components can be added by going to the Control Panel, selecting Programs and Features, and clicking Turn Windows features on or off. Make sure to check the IIS 6 Management Compatibility components under Internet Information Services.
Once I installed these components and rebooted I was able to debug.
EDIT: I still find that the process dies on my from time to time if I have other Internet Explorer browser windows open. Therefore, I have to make sure that the only Internet Explorer window that is open is the one that is debugging my Visual Studio 2005 code. I use FireFox to browse the web in parrallel if I need to.
This can happen if a stack overflow (no pun intended) occurs in your application. Stack overflows are usually caused by infinite recursion in your code.
I had the same problem since an update from latest weeks.
But solved by simply open the develompment tools and set the browser mode to ie7.
I get this if I have an existing IE window open when I start the debugger. Make sure you close all existing IE windows.
Using IE1 and VS 2003 (!) on Win 7 Enterprise N, I found that having additional IEs running made debugging impossible, but when starting the debug session after losing all IE windows worked.
Cost a lot of time and frustration.
I solved the issue on mine, by doing the following:
Go to IIS.
Go to Application Pools.
Click Advanced Settings on the relevant App Pool.
Find the key "Ide Time-out Action" and increase the value to something you think is right for you.
I have deployed an application written in ASP.NET 2.0 into production and it's experiencing some latency issues. Pages are taking about 4-5 seconds to load. GridView refreshing are taking around the same time to load.
The app runs fine on the develpment box. I did the following investigation on the server
Checked the available memory ... 80% used.
Cheched the processor ... 1%
Checked disk IO from perfmon, less than 15%
The server config is
Windows Server 2003 Sp2
Dual 2.0 GZH
2GB RAM
Running SQL Server 2005 and IIS only
Is there anything else I can troubleshoot? I also checked the event log for errors, it's clean.
EDITED ~ The only difference I just picked up is on the DEV box I am using IE7 and the clients are using IE6 - Could this be an issue?
UPDATE ~ I updated all clients to IE8 and noticed a 30% increase in the performance. I finally found out I left my debug=true in the web.config file. Setting that to flase got the app back to the stable performance... I still can't believe I did that.
First thing I would do is enable tracing. (see: https://web.archive.org/web/20210324184141/http://www.4guysfromrolla.com/webtech/081501-1.shtml)
then add tracing points to your page generation code to give you an idea of how long each part of the page build takes:
System.Diagnostics.Trace.Write(
"Starting Page init",
"TraceCheck");
//Init page
System.Diagnostics.Trace.Write(
"End Page init",
"TraceCheck");
System.Diagnostics.Trace.Write(
"Starting Data Fetch",
"TraceCheck");
//Get Data
System.Diagnostics.Trace.Write(
"End Data Fetch",
"TraceCheck");
etc
this way you can see exactly how long each stage is taking and then target that area.
Double check that you application is not running in debug mode. In your web.config file check that the debug attribute under system.web\compilation is set to false.
Besides making the application run slower and using more system memory you will also experience slow page loading since noting is cached when in debug mode.
Also check your page size. A developer friend of mine once loaded an entire table into viewstate. A 12 megabyte page will slip by when developing on your local machine, but becomes immediately noticeable in production.
Are you running against the same SQL Server as in your tests or a different one?
In order to find out where the time's coming from you could add some trace statements to your page load, and then load the page with tracing turned on. That might help point to the problem.
Also, what are the specs of your development box? The same?
Depending on the version of visual studio you have, Team Developer has a Performance Wizard you might want to investigate.
Also, if you use IE 8, it has a Profiler which will let you see how long the site takes to load in the browser itself. One of the first things to determine is whether the time is client side or server side.
If client side, start looking at what javascript you have and optimize / get rid of it.
If server side, you need to look at all of the performance counters (perfmon). For example, we had an app that crawled on the production servers due to a tremendous amount of JIT going on.
You also need to look at the communication between the web and database server. How long are queries taking? Are the boxes thrashing the disk drives? etc.