设为首页 收藏本站
查看: 950|回复: 0

[经验分享] 构建高性能.NET应用之配置高可用IIS服务器-第四篇 IIS常见问题之:工作进程回收机制(上)

[复制链接]
发表于 2015-8-13 02:47:28 | 显示全部楼层 |阅读模式
通过三篇文章的普及,相信大家对IIS应该有了一个基本的了解。那么从本篇文章开始,我们就开始进入IIS一些比较实际的话题:如何配置IIS,使得其性能尽可能的高。   
  系列文章:
  构建高性能.NET应用之配置高可用IIS服务器-第一篇:IIS必须掌握的知识
构建高性能.NET应用之配置高可用IIS服务器-第二篇 IIS请求处理模型
构建高性能.NET应用之配置高可用IIS服务器-第三篇 IIS中三个核心组件的讲解(上)
构建高性能.NET应用之配置高可用IIS服务器-第三篇 IIS中三个核心组件的讲解(下)


构建高性能.NET应用之配置高可用IIS服务器-第四篇 IIS常见问题之:工作进程回收机制(上)

         我们在本篇中主要讲述的就是“工作进程回收机制”,下面我们就来具体的看看。
         本篇文章的议题如下:
  
                 工作进程回收机制讲解
  基于时间的回收机制
  基于请求数的回收机制
  基于内存使用的回收机制
  基于活动状态的回收机制
                 
  工作进程回收机制讲解
  
         在IIS6和IIS7的应用程序池中,可以进行一系列的配置来控制如何启动和停止池中的工作进程。合理的配置可以使得应用程序的可用性更高,特别是出现问题的时候,可以尽可能的减少损失。通过配置,可以使得应用程序池中,一些运行的比较慢或者将要失败的进程可以被快速的结束,从而使用新的进程来取代它们。
  
         回收机制与启动机制不同,因为回收机制是属于比较智能的策略,回收机制允许一个进程在被回收之前先处理完现有的任务,而重启机制则是强制关闭。使用回收机制,可以在旧的进程还在处理之前的请求的时候,同时开启新的进程,使得新的请求被新进程处理。
  
         有一点要清楚的就是:当一个工作进程被回收的时候,任何保存在进程中的状态都会被清理掉,例如session,cache。如果我们要确保运行状态,例如session,cache等不随着工作进程的回收而清理,那么就必须采用其他的方式来保存状态,而不是直接保存在工作进程的内存中,例如,对session可以采用数据库存储的方式,对cache可以采用分布式缓存来实现。
  
  下面,我们就来看看工作进程被回收的几个策略,或者说,什么时候启动回收机制。
  在讲解之前,我们可以查看一下应用程序池中回收机制的配置,如图是IIS7的:
  

  
  
  点击“正在回收”之后,看到如下的界面:  
  



  除了上面的看出方式之外,我们还可以进入应用程序池的“高级设置”进程配置,如图:
  
  
  
  然后在“回收”进行设置,如图:
  

  
         大家可以看到,我们这里可以基于很多不同的策略进行配置,而这些也使我们本篇文章要讲的,下面我们就来具体的看看每一种回收策略以及具体的配置的信息。
  
  基于时间的回收机制
  
         这个回收策略应该是比较容易理解的,就是对时间进行设置,来决定什么时候,或者间隔多长时间来回收。
  
  固定时间收集的间隔
        
         通过这个配置项,我们可以设置应用程序池每个多长的时间(分钟)去对池中的工作进程进行资源的回收,默认是1760分钟,也就是一天。如果我们的应用程序在还没有达到这个时间间隔就失败了,出现了问题,那么,我们就要把这个值设置为失败时间的80%
  
         举例来说,如果一个应用程序,在1000分钟之类就失败,那么它所占用的是无法被回收的,因为回收的时间被设置为1740分钟之后,如果我们放任这种情况,那么服务器的资源就会被耗尽。此时,我们可以通过多次的数据取样,获取平均的失败时间间隔,假设是1000分钟,那么这个时候,我们就把这个“固定时间收集的间隔”设置为800分钟。这个配置在某些情况下可以是一个应急的解决方案,可以快速的搞定资源泄露的问题,但是需要技术人员真正的解决站点运行失败的原因。
  
  设置回收的时间间隔
         另外一种比较回收方法就是设置在一天中的那些时候去进行回收。设置如下:
        

  
        我们可以控制在哪个时间点去进行回收,特别实在诊断问题的时候。如果我们发现在某个点,站点总是不能出来请求或者资源的使用过多(例如,站点访问高峰值的时候),我们可以通过设置,使得资源尽快的被回收。
  
         今天就到这里,下篇接着讲述!
  系列文章链接:
  IIS负载均衡-Application Request Route详解第一篇: ARR介绍  
  IIS负载均衡-Application Request Route详解第二篇:创建与配置Server Farm
   IIS负载均衡-Application Request Route详解第三篇:使用ARR进行Http请求的负载均衡(上)
  IIS负载均衡-Application Request Route详解第三篇:使用ARR进行Http请求的负载均衡(下)
  IIS负载均衡-Application Request Route详解第四篇:使用ARR实现三层部署架构
  
  负载均衡原理与实践详解第一篇(重新整理)  
  负载均衡原理与实践详解第二篇(重新整理)  
  负载均衡原理与实践详解第三篇服务器负载均衡的基本概念-网络基础  
  负载均衡原理与实践详解第四篇使用负载均衡器的服务器群   
  负载均衡原理与实践详解第五篇负载均衡时数据包流程详解  
  负载均衡原理与实践详解第六篇健康检查机制详解(上)  
  负载均衡原理与实践详解第七篇健康检查机制详解(下)  
  负载均衡原理与实践详解第八篇网络地址转换(上)
  负载均衡原理与实践详解第八篇网络地址转换()
  负载均衡原理与实践详解第九篇服务器负载均衡技术进阶-会话保持(上)
负载均衡原理与实践详解 第十篇 服务器负载均衡技术进阶-会话保持(中)
负载均衡原理与实践详解 第十一篇 服务器负载均衡技术进阶-会话保持(下) 之:延迟绑定

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-98112-1-1.html 上篇帖子: 无法打开登录所请求的数据库DbName 。登录失败。 用户 'IIS APPPOOL\DefaultAppPool' 登录失败。 的解决方案 下篇帖子: 构建高性能.NET应用之配置高可用IIS服务器-第三篇 IIS中三个核心组件的讲解(上)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表