服务器应用程序池老是自动停止

服务器应用程序池老是自动停止,第1张

一、2003应用程序池自动死了,不能恢复了,一直出现 Service Unavailable 常见方法如下。

1:没有打SP1补丁的时候会出现这个IIS60假死问题,但现在微软都在自动更新里面出补丁了,一般你打好最新补丁后是不会出现此问题了。(所以现在的IIS假死与这个关系不是很大)

2:从IIS60开始CPU资源都在应用池里面限制了,不象以前的IIS5。所以假死的池的缘故就是池被拉死,你在网站打不开的时候可以看到你的某个应用池是禁用的,上面出现一个红叉。你鼠标右键启动网站又会自动恢复。 这个原因:大概是以下几个因数造成的。

(1):你限制了应用池的资源,限制得太小 比如:50这样或更少更多一点,这个时候如果你这个池下面的网站占用CPU太高,比如超过50% 那么5分钟后他就自动死了,手工默认建立的应用池默认是超过资源不 *** 作。

出现上面这个情况解决方法:1:不限制CPU资源,(这个是不可取的,不限制资源,有的程序有BUG占用资源厉害了的,服务器都会被拉死,你可能都无法 *** 作服务器。)2:在超过资源那里选择关闭,这个关闭默认是失败5次,90秒内恢复,一般默认就可。网站能自动恢复,这个关闭:不是永久关闭,意思是超过资源关闭,然后在某时间内自动恢复池。不 *** 作就是不恢复,这个是很多人的误区。

(2):内存限制 在IIS60应用池上面有虚拟内存和最大内存限制,如果你设置了这个。那么网站访问量大了 也会出现假死,所以不建议设置这里。默认就可。

3:就是服务器自身内存太小,网站运行当然需要使用到内存了,当内存不够的时候应用池也会死掉变成禁用。那么只有等内存全部释放出来才能恢复应用池了。出现这个情况:那么你就要考虑加内存或者检查到底是什么程序占用了内存了。比如MSSQL数据库,这个可是吃内存得大户啊,最好别和WEB服务器同时一个服务器上。很多人用1G内存做 2003系统,2003NET结构是很占用内存的,所以做服务器选2003还得把内存加到2G或更高才好。 内存不够上面 2点讲到的,是没办法 *** 作了,也无法自动恢复。

4:就是ACCESS数据库太大或查询太多,这个也会出现把IIS拉死,解决方法;修复ACCESS数据库,或尽量少用ACCESS数据库,升级至sqlserver数据库;或者在技术方面革新,像现在有些网站系统,风讯、动易等cms;pjblog、zblog等博客程序,都支持生成静态功能

5:不同网站用不同应用池:根据你自己实际情况而定,站点大的最好独立一个应用池,限制他的资源超过了自动回收,看上面(1)讲到的,这样就不影响其他站点。中型站点:多个网站共用一个应用池,比如5个站点用一个池,设置他资源时间等等。这样他们就算超资源了也不影响其他应用池的网站。

6:设置回收时间:很多人以为设置回收池越短越好,其实是错误的,每次回收当然是把内存回收回来了,但加重了一次服务器的负担,当服务器比较繁忙的时候,有可能导致其他应用池死。所以建议设置共1000就行了。其他独立池按照他网站流量而设置 可以设置600 也行,共用的不建议设置太短。

7:网站后台过不了多久自动退出又要重新登陆:这个情况就是你设置回收时间太短了,按照 6点设置吧。 不要设置什么20分、30分这样的,这样不好的。另外一个原因就是和站的响应设置时间有关,设置得稍长些。

8:windows 2003系统iis6访问本机的站点时提示“Service Unavailable”;

查看iis的应用程序池,状况提示为:未指定错误,同时应用程序池自动停止运行;

首先看你的服务开启没有

ASPNET State Service

IIS Admin Service

设置成自动启动

然后设置Internet信息服务(IIS)管理器下的

网站默认网站右键属性调调

或者看看下面的也行:

1:没有打SP1补丁的时候会出现这个IIS60假死问题,但现在微软都在自动更新里面出补丁了,一般你打好最新补丁后是不会出现此问题了。(所以现在的IIS假死与这个关系不是很大)

2:从IIS60开始CPU资源都在应用池里面限制了,不象以前的IIS5。所以假死的池的缘故就是池被拉死,你在网站打不开的时候可以看到你的某个应用池是禁用的,上面出现一个红叉。你鼠标右键启动网站又会自动恢复。 这个原因:大概是以下几个因数造成的。

(1):你限制了应用池的资源,限制得太小 比如:50这样或更少更多一点,这个时候如果你这个池下面的网站占用CPU太高,比如超过50% 那么5分钟后他就自动死了,手工默认建立的应用池默认是超过资源不 *** 作。

出现上面这个情况解决方法:1:不限制CPU资源,(这个是不可取的,不限制资源,有的程序有BUG占用资源厉害了的,服务器都会被拉死,你可能都无法 *** 作服务器。)2:在超过资源那里选择关闭,这个关闭默认是失败5次,90秒内恢复,一般默认就可。网站能自动恢复,这个关闭:不是永久关闭,意思是超过资源关闭,然后在某时间内自动恢复池。不 *** 作就是不恢复,这个是很多人的误区。

(2):内存限制 在IIS60应用池上面有虚拟内存和最大内存限制,如果你设置了这个。那么网站访问量大了 也会出现假死,所以不建议设置这里。默认就可。

3:就是服务器自身内存太小,网站运行当然需要使用到内存了,当内存不够的时候应用池也会死掉变成禁用。那么只有等内存全部释放出来才能恢复应用池了。出现这个情况:那么你就要考虑加内存或者检查到底是什么程序占用了内存了。比如MSSQL数据库,这个可是吃内存得大户啊,最好别和WEB服务器同时一个服务器上。很多人用1G内存做 2003系统,2003NET结构是很占用内存的,所以做服务器选2003还得把内存加到2G或更高才好。 内存不够上面 2点讲到的,是没办法 *** 作了,也无法自动恢复。

4:就是ACCESS数据库太大或查询太多,这个也会出现把IIS拉死,解决方法;修复ACCESS数据库,或尽量少用ACCESS数据库,升级至sqlserver数据库;或者在技术方面革新,像现在有些网站系统,风讯、动易等cms;pjblog、zblog等博客程序,都支持生成静态功能

5:不同网站用不同应用池:根据你自己实际情况而定,站点大的最好独立一个应用池,限制他的资源超过了自动回收,看上面(1)讲到的,这样就不影响其他站点。中型站点:多个网站共用一个应用池,比如5个站点用一个池,设置他资源时间等等。这样他们就算超资源了也不影响其他应用池的网站。

6:设置回收时间:很多人以为设置回收池越短越好,其实是错误的,每次回收当然是把内存回收回来了,但加重了一次服务器的负担,当服务器比较繁忙的时候,有可能导致其他应用池死。所以建议设置共1000就行了。其他独立池按照他网站流量而设置 可以设置600 也行,共用的不建议设置太短。

7:网站后台过不了多久自动退出又要重新登陆:这个情况就是你设置回收时间太短了,按照 6点设置吧。 不要设置什么20分、30分这样的,这样不好的。另外一个原因就是和站的响应设置时间有关,设置得稍长些。

8:windows 2003系统iis6访问本机的站点时提示“Service Unavailable”;

查看iis的应用程序池,状况提示为:未指定错误,同时应用程序池自动停止运行;

用事件查看器查看系统错误日志,发现如下提示:

-----------------------------------

应用程序-特定 权限设置未将 COM 服务器应用程序(CLSID 为

{A9E69610-B80D-11D0-B9B9-00A0C922E750}

)的 本地 激活 权限授予用户 NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20)。可以使用组件服务管理工具修改此安全权限。

解决方法,给NETWORK SERVICE 加上访问iis服务的权限,具体方法如下:

点击“开始”-“控制面板”-“管理工具”-“组件服务”-“计算机”-“我的电脑”-“DCOM”选项,

选择其下的“IIS ADMIN SERVICE”,右健选择“属性”,找到“安全”,在“启动和激活权限”中编辑“自定义”,添加帐号“NETWORK SERVICE ”,给该帐号赋予“本地启动”和“本地激活”的权限,重新启动IIS之后再访问同一站点,则一切正常。

9:重启IIS中的特定应用程序池命令和自动重启的方法

在 *** 作系统是Windows server 2003 SP1+的情况下,可以用以下命令部分重启IIS应用程序池:

cscriptexe c:\windows\system32\iisappvbs /a "DefaultAppPool"

其中/a 代表alternatively,"DefaultAppPool"代表应用程序池的实例名。如果要设置自动重启这个应用程序池,可以尝试放在批处理中,用计划任务调用此批处理即可。很多人觉得计划任务不安全,都要禁掉,事实上,计划任务的不安全是建立在其它方面不安全的前提上的,如果由于其它方面的不安全,被放入执行程序,计划任务执行,这和计划任务没有直接关系。当然,关掉,是会减少一些安全隐患,这是不错。

-------------------

要分

应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制

服务器经常产生“应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程 ID 是 '2068'。”的错误,导致iis处于假死状态,经了解是IIS应用程序池的设置问题。解决方法如下:

Internet 信息服务(IIS)管理器->应用程序池->DefaultAppPool->右击属性

一、回收

1、回收工作进程(分钟):选中,值为1740

2、回收工作进程(请求数目):不选(原先设置为35000)

3、在下列时间回收工作进程:不填

4、消耗太多内存时回收工作进程:全不选。(2、3、4项可能避免了在访问量高的时候强制回收进程可能引发的服务器响应问题,导致iis假死不响应)

二、性能

只选中空闲超时20分钟。其他都不选。WEB园最大工作进程数为1(默认)。注意web园这里一定要保持默认,如果填写其他超过1的数字就会导致一些网站程序的后台程序打不开或者刷新不停。

原来的请求队列限制为4000,现在无限制。

三、运行状况

前两项都起用,是原来的默认设置。启动时间限制90秒,关闭时间限制180秒。

启动快速失败保护的钩去掉!

为了避免真的遇到很多错误时没有提示,可以不关闭,只是把快速保护的保护范围加大些,例如失败数50次 时间段5分钟 则关闭对应的程序。

“关闭时间限制180秒”是必须的,因为进程关闭的时间,原来为90秒限制,是默认值,如果进程关闭时间超过90秒,则认为超时,从而出现:进程关闭时间超过了限制 日志,所以,适当延长这个时间,可以避免这种错误>

一、原因:IIS应用程序池的设置问题

解决方法:

Internet 信息服务(IIS)管理器->应用程序池->DefaultAppPool->右击属性

二、原因:独立进程的 内存堆戋消耗完了,IIS不能创建更多的进程工作空间来处理

解决方法:

1 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC

2

在Parameters键下新建一个DWORD项,名字为:UseSharedWPDesktop 值为1 重启IIS

三、原因:数据库连接无法释放

解决方法:

在连接串里加入以下语句

Pooling=true; MAX Pool Size=512;Min Pool Size=50;Connection Lifetime=30

应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制

服务器经常产生“应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程 ID 是 '2068'。”的错误,导致iis处于假死状态,经了解是IIS应用程序池的设置问题。解决方法如下:

Internet 信息服务(IIS)管理器->应用程序池->DefaultAppPool->右击属性

一、回收

1、回收工作进程(分钟):选中,值为1740

2、回收工作进程(请求数目):不选(原先设置为35000)

3、在下列时间回收工作进程:不填

4、消耗太多内存时回收工作进程:全不选。(2、3、4项可能避免了在访问量高的时候强制回收进程可能引发的服务器响应问题,导致iis假死不响应)

二、性能

只选中空闲超时20分钟。其他都不选。WEB园最大工作进程数为1(默认)。注意web园这里一定要保持默认,如果填写其他超过1的数字就会导致一些网站程序的后台程序打不开或者刷新不停。

原来的请求队列限制为4000,现在无限制。

三、运行状况

前两项都起用,是原来的默认设置。启动时间限制90秒,关闭时间限制180秒。

启动快速失败保护的钩去掉!

为了避免真的遇到很多错误时没有提示,可以不关闭,只是把快速保护的保护范围加大些,例如失败数50次 时间段5分钟 则关闭对应的程序。

“关闭时间限制180秒”是必须的,因为进程关闭的时间,原来为90秒限制,是默认值,如果进程关闭时间超过90秒,则认为超时,从而出现:进程关闭时间超过了限制 日志,所以,适当延长这个时间,可以避免这种错误>

应用程序池达到请求的最高限制就会出现服务器假死。

打开IIS 你就会看到应用程序池,默认只有一个应用程序池,查看应用程序池的属性,会发现他的回收时间,默认多达,1740分钟,就是说,需要在1740分钟后才回收此应用程序池,如果在这个时间内,达到请求的最高限制,那么就会出现ASP假死的情况,这个就是大型网站出现假死的情况,反而,小型网站确不会出现这样的情况,因为他请求少,流量少,还没达到限制数量。当然要看你的服务器上网站数目而定。单个网站解决方法:把应用程序池回收时间缩短到300-600分钟,其间回收过程中,需要占用一点CPU资源,没办法,为了稳定性,再把回收时间设为凌晨5点。

503错误是一种>

以上就是关于服务器应用程序池老是自动停止全部的内容,包括:服务器应用程序池老是自动停止、web网站的iis应用程序池频繁假死、IIS6 程序池错误< 'DefaultAppPool' 提供服务的进程意外终止>等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/9452477.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-28
下一篇 2023-04-28

发表评论

登录后才能评论

评论列表(0条)

保存