共享环境中 IIS7 中应用程序池回收的最佳设置是什么？
共享环境中 IIS7 中应用程序池回收的最佳设置是什么？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
共享环境中 IIS7 中应用程序池回收的最佳设置是什么？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（4）
作为托管者，您肯定希望回收内存和资源。 时间、潜在的请求限制和 CPU。 您希望对这些限制采取非常积极的态度，但请确保将它们发布给您的客户。
内存 - x86 机器为 512，可能为 768。对于 x64，您可以根据每台服务器的主机数量将其设置得更高。 您只需小心并观察应用程序池在内存问题上的回收事件。
时间 - 我们通常在凌晨 1 点左右进行回收（第一个站点 1:01，第二个站点 1:11，第三个站点 1:21，这样您就不会同时进行所有回收）
请求限制 - 35,000 是IIS6 的默认值，但这个数字是相当任意的，并且非常依赖于相关站点。 对于小型使用网站，夜间回收早在您收到 35k 请求之前就会达到。
CPU - 95%/1分钟限制/KillW3WP，但请谨慎使用。 我对此的理解是，如果 CPU 在该工作进程的 1 分钟限制内达到 95% 以上，则当 Action 设置为 KillW3WP 时，该工作进程将被终止，并且无法在剩余的限制内重新启动。 您可能想首先尝试 NoAction，然后仔细观察事件日志。
回收事件日志 - 您希望确保为您设置的每个事件阈值记录应用程序池回收 - 即，如果您基于请求限制进行限制，请确保启用请求限制日志记录。
要记住的一件事是，您应该在 ://www.iis.net/learn/get-started/planning-your-iis-architecture/the-configuration-system-in-iis-7" rel="noreferrer">machine.config：
不是设置此选项将允许站点打开调试，这允许请求无限超时 - 对于托管服务商来说并不完全理想......
As a Hoster, you definitely want to recycle on Memory & Time, potentially Request limits and CPU. You want to be pretty aggressive about these limits, but make sure you publish them to your clients.
Memory - 512 for an x86 box, maybe 768. For x64, you can set this much higher depending on the number of hosts per server. You just have to be careful and watch your app pool recycle events on memory issues.
Time - We typically recycle at 1 am in the morning, plus or minus (first site 1:01, second 1:11, third 1:21, just so you don't have all recycling at the same time)
Request limit - 35,000 was the default for IIS6, but this number is quite arbitrary, and very dependant on the site in question. For small usage sites, the nightly recycle will hit long before you get 35k requests.
CPU - 95%/1 minute limit/KillW3WP, but use this carefully. My understanding of this is that if the CPU hits 95%+ over the 1 minute limit for this worker process, the worker process gets killed and is unable to restart for the remainder of the limit when Action is set to KillW3WP. You might want to try NoAction initially and just watch your event logs carefully.
Recycle Event Logs - You want to make sure you are logging app pool recycles for each event threshhold that you set - i.e. if you limit based off of requests limits, make sure that Request Limit logging is enabled.
One thing to remember is that you should set
retail="true"in the<deployment>element in your machine.config:Not setting this will allow a site to turn debugging on, which allows unlimited timeouts in requests - not exactly ideal for a hoster...
提示：当您回收应用程序时，所有会话变量都会被销毁......因此请小心！
恕我直言，保留默认值。
Tip: When you recycle your app, all your session variables are destroyed... so caution on this!
IMHO, keep the defaults.
如果您的站点交通繁忙，请使用较长的回收计划。 如果您的站点流量较低，请使用较短/默认的计划来节省内存。
我从 Al Zabir 的博客中了解到这一点：http://msmvps.com/blogs/omar/archive/2008/10/04/best-practices-for-creating-websites-in-iis-6-0.aspx< /a>
Daniel S. 是对的，您的会话变量在回收时会被破坏，因此请确保您对此进行了良好的测试，或者在获取会话对象时具有良好的错误保护/恢复。
If you have a heavy traffic site, use long recycle schedule. If you have a low traffic site use shorter/default schedule to save memory.
I learned this from Al Zabir's blog: http://msmvps.com/blogs/omar/archive/2008/10/04/best-practices-for-creating-websites-in-iis-6-0.aspx
Daniel S. is right, your session variables get destroyed on recycle, so make sure you test this well or have good error protection/recovery when getting your session objects.
您需要根据您的需要进行设置，考虑您拥有的内存量以及站点/Web 应用程序的使用高峰时间。
还要考虑站点/Web 应用程序的内存使用情况，就好像存在内存泄漏一样，您可能会比您想象的更频繁地回收内存。
权衡任何泄漏与回收成本，如上所述，您将丢失状态变量。
you need to cater the settings to your needs, take into account the amount of memory you have and the peak times of usage for your site/web application.
Also take into account the memory usage of your site/web application as if there are memory leaks you might be recycling more often then you think.
Weigh up any leaks against the cost of recycling, as stated above you will lose state variables.