将CPU下的时间间隔从5更改为0。
进程模型下的空闲超时从20更改为0。
回收中的正常时间间隔从1740到0。
这够了吗？我对所更改的项目有特定的疑问：
CPU下的“限制间隔”设置具体意味着什么？这是否意味着如果超过一定的CPU使用率，应用程序池将被回收？
“回收”到底是什么意思？应用程序是否完全拆除并重新启动？
“工作进程关闭”和“应用程序池回收”之间有什么区别？进程模型下的空闲超时文档讨论了如何关闭工作进程。虽然“回收”下的“定期时间间隔”文档讨论了应用程序池回收。我不太了解两者之间的区别。我以为w3wp.exe是运行应用程序池的工作进程。有人可以解释两者之间的区别吗？
之所以拥有IIS7和IIS7.5标签是因为该应用程序将在两者中运行，并且希望答案在两个版本之间是相同的。 br />
图像参考：
#1 楼
回收回收通常是*，其中IIS启动一个新进程作为您的应用程序的容器，然后将旧进程交给ShutdownTimeLimit，以免被杀死。
*-通常：请参见DisallowOverlappingRotation /“禁用重叠回收”设置
，它具有破坏性，因为原始过程及其所有状态信息都将被丢弃。使用进程外会话状态（例如，状态服务器或数据库，或者如果状态很小，甚至使用cookie）都可以解决此问题。
但是默认情况下它是重叠的-意思是说，由于新流程已启动并已挂接到请求队列，因此中断时间得以最小化，而新流程则告诉旧流程“您有[ShutdownTimeLimit]秒消失。请遵守。” >设置
问题：该页面上的所有设置都以某种方式控制回收。 “关机”可能被描述为“主动回收”-流程本身决定是时候去了，并有序地退出。
反应回收是WAS发现问题并采取措施的地方（确定合适的替代品W3WP之后。）
现在，有些东西可能导致一种或另一种形式的回收：
一个ISAPI判定它不健康
/>任何模块崩溃
空闲超时
cpu限制
调整应用程序池属性
因为您的妈妈可能曾一声尖叫：“停止选择否则，它将永远变得更好！“
” ping“失败*实际上并不是ping本身，因为它使用了命名管道-更多的“生命检测”
以上屏幕快照中的所有设置
操作方法：
通常：
禁用空闲超时。 20分钟不活动=繁荣！下一个传入请求的新过程。将其设置为零。
禁用定期时间间隔-29小时的默认时间间隔已被各方描述为“疯狂”，“烦人”和“聪明”。实际上，其中只有两个是正确的。工人需要杀死它的过程。您需要手动回收应用程序池以使设置生效，这使您可以预先设置设置，然后使用更改窗口通过回收过程应用设置。
作为一般原则，请启用ping。那就是你的安全网。我见过人们将其关闭，然后网站有时无限期挂起，导致出现恐慌...因此，如果设置对于您看似非常非常缓慢的应用程序而言过于激进，请将其关闭并查看您得到了什么，而不是将其关闭。 （除非您通过自己的监视过程为挂起的W3WP设置了自动崩溃模式转储）
足以使行为良好的过程永远存在。如果它死了，肯定会被替换。如果挂起，则ping应将其恢复，并在2分钟内开始新的轮询（默认情况下；最坏情况的计算应为：达到ping频率+ ping超时+在请求再次开始工作之前的启动时间限制）。 >
CPU限制通常并不有趣，因为默认情况下它是关闭的，并且它也被配置为不执行任何操作。如果将其配置为终止该进程，那么肯定是一个回收触发器。丢开。对于IIS 8.x，请注意，CPU限制也可以选择。
（IIS）AppPool不是（.Net）AppDomain（但可能包含一个/某些）
但是...然后，我们进入.Net土地和AppDomain回收，这也可能导致状态丢失。 （请参阅：https：//blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/）
简短的版本，您可以通过触摸内容文件夹中的web.config文件（同样要进行选择！），或通过在该文件夹中创建一个文件夹或ASPX文件或其他方式来实现。与应用程序池回收一样具有破坏性，减去本地代码启动成本（它纯粹是托管代码（.Net）概念，因此此处仅发生托管代码内容）。
防病毒软件还可以在扫描web.config文件时触发此操作，从而引起更改通知，从而导致....
评论
等待等待等待...为什么从防病毒中读取web.config会触发更改通知？任何无缘无故“接触” web.config的防病毒软件都是垃圾桶。
– Shiv
19年1月10日在1:41
AV可能不仅会读取，而且可能会写入-例如写入备用数据流，记录上次用于扫描文件的引擎版本。一想到。
– TristanK
19年2月22日在4:02
#2 楼
请检查为什么我们要回收我们的应用程序池？如果浏览Web来查找将应用程序池配置为定期自动回收的原因，您将很难找到与内存问题无关的合理答案。就像整个社区已经普遍接受这样一个事实，即我们的Web应用程序（或IIS中托管的服务层）将需要回收以避免内存问题。
我一直认为如果您的代码需要定期重新启动以保持正常工作，那么显然是错误的。您的代码中某处存在一个错误，您需要修复该错误，而不是偶尔重新启动该过程以使问题“消失”。并确保我们的应用程序可以正常运行。
评论
原因之一是.NET对“大对象”（通常为85K或更大的东西）使用单独的堆，当发生垃圾收集时，该堆不会压缩（尽管在.NET 4.5.1中，我认为它们添加了压缩LOH的选项），并且在ASP.NET中，当在服务器端呈现HTML时，通常会看到85K的HTML（尤其是对于重复的内容，如表格和网格），并且该HTML基本上只是服务器上的一个巨大的String对象，并且如果符合一个大对象，它导致大对象堆碎片化，最终导致OutOfMemoryException，因此回收
–不需要
17年7月21日在21:30
@nothingisnecessary无论压缩如何，一旦请求完成并且发生垃圾回收，是否不会释放所有大的HTML字符串？为避免瑞士奶酪内存（零散的可用内存空间），可能需要对流行的长寿命对象（例如应用程序变量甚至会话变量）进行压缩，但是如果应用程序避免使用大量，大而长的对象生存的对象，永不回收应用程序会有任何问题吗？
– YipYip
19年11月4日在20:32
如果未压缩可用空间，则会发生碎片。如果堆变得如此分散，以至于没有一个连续的地址块足以存储您的对象，则.NET会抛出OutOfMemoryException。从理论上讲，如果使用压缩并且总内存使用量保持在限制范围内，则可以避免这种情况。 “永不回收该应用程序会有任何问题吗？”我不知道您在代码中创建了哪种错误..所以可能会出现问题。但是，如果您了解内存的流动方式，则可能会使内容长期处于浮动状态。
–不需要
19年11月4日在23:08
就我的经验而言，LOH压缩问题非常罕见。当出现问题时，定期调度LOH压缩（因为这是在刷新应用内缓存，因此这是双重好处）解决了一个问题。仅仅因为LOH碎片化并不意味着它就变得不可用，特别是如果大多数LOH对象本身都是瞬态的。
–user2864740
20 Sep 15 '20：47
评论
您在哪里从IIS设置那里获得了该屏幕截图？这是“高级应用程序池”属性表。