是什么导致IIS应用程序池回收? [英] What can cause IIS app pool to recycle?

问题描述

我当前在会话变量中遇到一些不稳定，并认为应用程序池是错误的出处.我找不到的是此问题的可能原因列表.除了计划的回收利用之外，什么原因可能导致应用程序池自行回收利用?

I am currently experiencing some instability in my session variables and believe the app pool is where the error is coming from. What I cannot find is a list of possible culprits for the issue. What can cause the app pool to recycle on its own, other than a scheduled recycle?

推荐答案

编辑:链接变为404时显示全文:

EDIT: Full Text in the event that the link goes 404:

如果您的应用程序崩溃，挂起和死锁，它将导致/要求对应用程序池进行回收才能解决，但是有时您的应用程序池莫名其妙地被回收而没有明显的原因.这通常是配置问题，或者是由于您正在应用程序目录中执行文件系统操作.

If your application crashes, hangs and deadlocks it will cause/require the application pool to recycle in order to be resolved, but sometimes your application pool inexplicably recycles for no obvious reason. This is usually a configuration issue or due to the fact that you're performing file system operations in the application directory.

为了消除，我想我会列出最常见的原因.

For the sake of elimination I thought I'd list the most common reasons.

应用程序池设置
如果您检查应用程序池的属性，则会看到许多用于回收应用程序池的设置.在IIS6中，它们是:

Application pool settings
If you check the properties for the application pool you'll see a number of settings for recycling the application pool. In IIS6 they are:

回收工作者进程(以分钟为单位)
回收工作者进程(在请求中)
在以下时间回收工作进程
最大虚拟内存
最大已用内存
这些设置应该很容易解释，但是，如果您想了解更多信息，请查看此MSDN文章

Recycle worker processes (in minutes)
Recycle worker process (in requests)
Recycle worker processes at the following times
Maximum virtual memory
Maximum used memory
These settings should be pretty self explanatory, but if you want to read more, please take a look at this MSDN article

machine.config的processModel元素 如果您正在运行IIS5或IIS5隔离模式，则必须查看processModel元素.您应该最关注的属性是:

The processModel element of machine.config If you're running IIS5 or the IIS5 isolation mode you'll have to look at the processModel element. The Properties you should pay the closest attention to are:

memoryLimit
requestLimit
超时
memoryLimit

memoryLimit的默认值为60.仅当32位计算机上的内存很少时，才需要使用此值. 60代表系统总内存的60％.因此，如果您有1 GB的内存，则工作进程达到600 MB的内存使用量后将自动重新启动.另一方面，如果您有8 GB，则理论上该进程将在达到4,8 GB时重新启动，但是由于它是32位进程，因此永远不会增长到如此之大.有关原因的更多信息，请参见我关于32位进程的文章.

memoryLimit
requestLimit
timeout
memoryLimit

The default value of memoryLimit is 60. This value is only of interest if you have fairly little memory on a 32 bit machine. 60 stands for 60% of total system memory. So if you have 1 GB of memory the worker process will automatically restart once it reaches a memory usage of 600 MB. If you have 8 GB, on the other hand, the process would theoretically restart when it reaches 4,8 GB, but since it is a 32 bit process it will never grow that big. See my post on 32 bit processes for more information why.

requestLimit
默认情况下，此设置为无限"，但是例如，如果将其设置为5000，则ASP.NET将为它处理5000个请求后启动一个新的辅助进程.

requestLimit
This setting is "infinite" by default, but if it is set to 5000 for example, then ASP.NET will launch a new worker process once it's served 5000 requests.

超时

默认超时是无限"，但是您可以在此处设置工作进程的生存期.一旦达到超时，ASP.NET将启动一个新的工作进程，因此将其设置为"00:05:00"将每五分钟回收一次应用程序.

timeout

The default timeout is "infinite", but here you can set the lifetime of the worker process. Once the timeout is reached ASP.NET will launch a new worker process, so setting this to "00:05:00" would recycle the application every five minutes.

其他属性

processModel元素内还有其他属性，这些属性将导致您的应用程序池回收，例如responseDeadlockInterval.但是，这些其他设置通常取决于出现问题或触发异常.如果您陷入僵局，那将是您的主要关注点.更改responseDeadlockInterval设置并不能解决问题.您需要处理死锁本身.

Other properties

There are other properties within the processModel element that will cause your application pool to recycle, like responseDeadlockInterval. But these other settings usually depend on something going wrong or being out of the ordinary to trigger. If you have a deadlock then that's your main concern. Changing the responseDeadlockInterval setting wouldn't do much to resolve the situation. You'd need to deal with the deadlock itself.

编辑和更新

ASP.NET 2.0依赖于文件更改通知(FCN)来查看应用程序是否已更新.根据更改，应用程序池将回收.如果您或您的应用程序要在应用程序文件夹中添加目录或从中删除目录，那么每次都会重新启动应用程序池，因此请小心使用这些临时文件.

Editing and updating

ASP.NET 2.0 depends on File Change Notifications (FCN) to see if the application has been updated. Depending on the change the application pool will recycle. If you or your application is adding and removing directories to the application folder, then you will be restarting your application pool every time, so be careful with those temporary files.

更改以下文件也会触发应用程序池的立即重启:

Altering the following files will also trigger an immediate restart of the application pool:

web.config
machine.config
global.asax
bin目录或其子目录中的任何内容
更新.aspx文件等会导致重新编译，最终也会触发应用程序池的重新启动.在system.web下有一个compilation元素的属性，称为numRecompilesBeforeAppRestart.默认值为20.这意味着20重新编译后，应用程序池将回收.

web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
Updating the .aspx files, etc. causing a recompile will eventually trigger a restart of the application pool as well. There is a property of the compilation element under system.web that is called numRecompilesBeforeAppRestart. The default value is 20. This means that after 20 recompiles the application pool will recycle.

子目录问题的解决方法
如果您的应用程序确实依赖于添加和删除子目录，则可以使用链接来创建目录连接.方法如下:

A workaround to the sub-directory issue
If your application really depends on adding and removing sub-directories you can use linkd to create a directory junction. Here's how:

创建要从FCN中排除的目录，例如c:\ inetpub \ wwwroot \ WebApp \ MyDir 在wwwroot之外的某个地方创建一个单独的文件夹.例如. c:\ MyExcludedDir 使用链接链接两个:链接c:\ inetpub \ wwwroot \ WebApp \ MyDir c:\ MyExcludedDir 在c:\ inetpub \ wwwroot \ WebApp \ MyDir中所做的任何更改实际上都将在c:\ MyExcludedDir中发生，因此FCN不会注意到它们.

Create a directory you'd like to exclude from the FCN, E.g. c:\inetpub\wwwroot\WebApp\MyDir Create a separate folder somewhere outside the wwwroot. E.g. c:\MyExcludedDir use linkd to link the two: linkd c:\inetpub\wwwroot\WebApp\MyDir c:\MyExcludedDir Any changes made in the c:\inetpub\wwwroot\WebApp\MyDir will actually occur in c:\MyExcludedDir so they will go unnoticed by the FCN.

回收应用程序池真的那么糟糕吗? 您确实不必回收应用程序池，但是如果您要处理应用程序中的内存泄漏，并且需要花些时间来修复它，那么回收应用程序池绝对是个好主意. />

Is recycling the application pool really that bad? You really shouldn't have to recycle the application pool, but if you're dealing with a memory leak in your application and need to buy time to fix it, then by all means recycling the application pool could be a good idea.

会话状态如何?

好吧，如果您正在运行进程中的会话状态，那么很明显，每次回收应用程序池时都会重置它.如果您需要熟悉状态服务器选项，那么我建议您看一下此条目.

What about session state?

Well, if you're running in-process session state, then obviously it's going to be reset each and every time the application pool is recycled. If you need to brush up on your state server options, then I recommend taking a look at this entry.

这篇关于是什么导致IIS应用程序池回收?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！