I am totally new in web programming... Now I am working on an already implemented ASP.NET MVC application which is deployed in IIS. This app is bound to an application pool which has only one worker process. At this moment, I am trying to understand what happens if the worker process freezes/hangs due to an uncontrolled exception thrown by app code. So may someone explain me it?
What we have observed is that when this happens, application stops working correctly and we need to restart its application pool in order to app begins to work correctly again. After observing this behavior, I have a doubt..... In application pool advanced configuration, under process model, the ping maximum response time (seconds) is set to 90 so as far as I know, when application pool pings the worker process and it does not respond because it is hang, after 90 seconds then worker process should terminate, but it seems it is not terminating because when this happens we need to restart application pool in order to app works again.... so Why in this case worker process does not terminate?
First off, you have "only" one Worker Process and should probably keep it that way. Often times Web Gardening causes more issues than it helps, particularly with .NET Apps. Second, you say it freezes/hangs due to "uncontrolled" (unhandled?) exception thrown by app code. Why do you think this is the case. Do you have an error page or something indicating its an exception? The "ping" process checks if the process is still doing work, but not necessarily finishing requests. So from the perspective of WAS, IIS is still responding.
If you want to troubleshoot, you could investigate getting a memory dump with DebugDiag and perform some automated analysis on it. https://support.microsoft.com/en-us/help/919792/how-to-use-the-debug-diagnostics-tool-to-troubleshoot-a-process-that-h
Related
I have an ASP.NET MVC application deployed on IIS 8.5 in a Web server and I would like to know the differences between these two features for the setting "Idle Time-out action".
If process is suspended, are the memory and resources used by the process removed and freed? I think it is good to remove and free memory used to avoid memory leaks so I usually use Terminate feature.
I think you should choose Suspend or Terminate according to your application environment.
Normally, to configure Idle Worker Process Page-Out for a Single Application Pool, we choose Terminate, to configure Idle Worker Process Page-Out as a Default for Application Pools, we choose Suspend.
IIS provides the administrator with an option of timing out a worker process that is idle for a specified period of time. This is a good option for sites that are not accessed very often because it frees up system resources when the site is idle. The disadvantage is that the next time the site is accessed, the user will need to wait for the worker process to start again.
In Idle Time-out action, it provides an option of suspending an idle worker process rather than terminating it. A suspended worker process remains alive but is paged-out to disk, reducing the system resources it consumes. When a user accesses the site again, the worker process wakes up from suspension and is quickly available. When an idle worker process is terminated, the worker process is shut down and the startup period will be longer when the site is subsequently accessed.
I realize that this question is getting "old" in internet time but I did want to point out one thing. While I agree with samwu and upvoted his answer, the OP mentioned in the question and again in a comment above that he wants to avoid potential memory leaks. Suspend will NOT help with that because the process is not terminated so Windows cannot reclaim the "leaked" memory. "Suspend" is to App Pools as "Hibernate" is to your dekstop/laptop. If there is a problem in/with memory and you Hibernate your computer, it will still be there when you come out of hibernation
I have multiple servers (2012 R2 with IIS 8.5) that have shared configuration, shared vanity URL (f5 load balanced), and host several different applications. One of the applications (an ASP.NET MVC web app) is rarely used (maybe once or twice a week) but when it needs to be used, it needs to load quickly.
I've set the AppPool to have a Start Mode of "AlwaysRunning", and a Recycling -> Regular Time Interval to 0, but it seems like every time I hit the app, it takes forever to load (like 10-20 seconds) but subsequent page requests happen instantly.
Is there another setting that I need to set to keep the app warmed up? The app has Kerberos Authentication and access is limited to one security group (that I'm not even a member of), so I can't use external PowerShell scripts to manually keep it warm.
You can check to see if the application pool is running before you hit the app.
If you click on your server name in IIS then click on "Worker Processes" you'll see all the Process ID's of the different application pools and that state.
This way you can confirm the app pool is running, before you access the application. This will help you narrow down where the problem exists.
1) Is the app pool running?
2) Is my app loaded in my app pool?
If 1 checks out, then move on to step 2 and check to see if the libraries of that application is loaded up in that Process ID.
Check your event log for application pool failures.
If you have some asynchronous initialisation/maintenance task which is started in parallel with the request or with some delay and subsequently fails, it can make the request (and some afterward) succeed but kill the application pool shortly after. This would exhibit these exact symptoms.
I have an ASP.NET MVC web application that uses the Quartz.net library to execute tasks on a daily schedule. I found out pretty quickly that IIS terminates/suspends the app pool after a period of inactivity. I have changed the config for that app pool to avoid this behavior, as follows:
Start Mode: Always Running
Idle Time Out (minutes): 0
Idle Time Out Action: Suspend
Generate Recycle Log Entry: True [for all sub-properties]
Regular Time Interval: 0
Specific Time Interval: TimeSpan[] Array [empty]
The only possible property I could see that might still kill my app is
Ping Enabled: True
It is set to kill any worker processes that don't respond within 90 seconds.
I am hesitant to change this property because I don't want to introduce resource leaks or anything like that.
These changes seemed to work for the past few days, but my job failed to execute again this morning.
So my question is, what can I look for in the event viewer or elsewhere that would indicate that the process/app was suspended or terminated?
I am not asking for how to improve my implementation - I am aware that a Windows Service or scheduled task, with persistent storage, would be better. I want to understand why this is happening, and where to look to find out when and why the app pool has stopped or started. I can't seem to find anything in the event viewer but perhaps I am looking in the wrong place.
Thanks in advance.
Would it be possible that there were unhanded exceptions which could crash the appPool. I think such things can be seen from Event Viewer.
I have modified the SimpleChatServer example of EventMachine to work with a Rails App as a chat server. I initialize the chat server in a seperate thread as follows.
Thread.new {
puts "I entered a new thread"
EventMachine.run do
puts "I entered a new thread"
EventMachine.start_server("0.0.0.0", 3100, SimpleChatServer)
end
}
I have hosted my app on a VPS running apache and am using Phusion Passenger to serve the rails app. The chat server works perfect except for one problem: The server stops automatically after a few minutes. When I check the error log i find nothing related to the shutdown. An interesting thing that I have observed however is a strange behavior of the shutdown: During day time in my location (11 am - 5 pm) the chat server stops after a few minutes of starting (My timezone is 10 hours ahead of my server's timezone). However during nighttime at my side the server keeps on running without a shut down. This strange behavior is bogging down my mind.
My own assumption is that during my day time, the VPS has more load to handle and thus it kills the Chat Server thread. Can I somehow avoid that? Also I would love to know if there is any other reason for this strange behavior. Please help me with this
Addition: When I check my error log I see this.
"[ 2015-03-06 08:00:20.5859 25041/7f20f1439700 agents/HelperAgent/Main.cpp:722 ]: Disconnecting long-running connections for process 25069"
Here 25069 is the PID of my chat server. How can i avoid this? How can I instruct linux not to kill my process ever?
A long while back I found the solution to this in a thread on github. The process gets killed because passenger kills idle applications to save memory. In order to disable this and keep my process running, I needed to set max_pool_idle_time to 0 in my passenger configuration. Here is a link to the original thread: https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx.html#_configuring_phusion_passenger
I have a project in asp.net mvc, my hosting is using IIS6, and the first request after the website sit's idle is very slow.
I looked at, http://forums.asp.net/t/1418959.aspx and asked the hosting for this settings.
They say that the actual settings are:
"The pool is set with Idle Timeout disabled, Rapid-fail enabled and with a single worker process."
But still slow at the first request. Do you have any other clues?
Thanks in advance,
Alfredo
You are probably a victim of worker process recycling. Ask your host how often the worker processes are recyled.
When a worker process is recycled, it has to recompile and restart the entire web application, and that's what causes the slowdown.
This is natural.
IIS is often configured to shut down the website if it's a certain age or if there hasn't been a request in awhile. Your website has to be loaded (and possibly compiled) when the first request comes after asp.net has been shut down by IIS.
The common solution is to precompile your website before publishing it to the server.
Just a guess, but perhaps you are caching some data, that needs to be refreshed after the site has been idle for some time ?
If this is not the case, then my guess would be that the worker process has been shut down for some reason (it could be for some other reason than the idle timeout in IIS). If you need to check whether this might be the case, you could add some code to the Application_Start event that logs the startup event to a file or whatever logging you have in place. After some time in operation, you can examine the logs and see, how many Application_Start events has occured.