Mikel
转载：http://www.linwan.net.cn/archives/2758.html
http://www.linwan.net.cn/archives/2759.html
今天又又发现了服务器出现强大的内存占用情况，区区的一G物理内存，不仅占完不说，还把虚拟内存还占了一半，这样，总内存达到了1.7G左右，这时，服务器基本要处于无法响应的状态了。好在是双核的。事实上此时的cpu占用率反而是非常低的。
以前说过类似的故障情况，服务器上安装了dz论坛，也安装了虚拟股市插件以及其他一些小插件，包括那个首页的四格调用插件，但就算如此，也不应该出现内存占用如此之大的情况，不管怎么样，还是要分析下问题所在。
月 光前天发布了一条管理服务器的十大武器，那个分析日志的，当时觉得还不错，就大老远的跑到老外网站上下了一个lite版本（免费的），看有语言包，想着说 不定有中文的，也下了一个，还有一个有关城市的数据状态库，也一并下了下来，哪知道，一番安装下来，语言包也没中文的（很多软件是不是对中国市场有些小 视？不是，主要中国人有正版的太少了，这个原因可能性比较大吧），运行起来分析了下，感觉不出什么效果，还不如直接把日志下载下来，用文本来看。
没 直接看iis的运行日志，直接把httperr日志给下了下来，到目录里面一看，果然有问题：一般httperr日志默认大小是1M，到了之后自动延续建 立，以前的这个日志，一天一夜连一M都不到，我看了下最近几天的，一天几乎要产生六七M，这绝对不正常了。把日志下载到本地，打开一个看了下，果不其然， 出现了大量的- Timer_ConnectionIdle -错误，有关这个问题，本博前些天分析过，当时引用那位哥们的话，就是有人和他的站在较劲，他就把响应保持时间设置小了，查了直微软的这篇文章：http://support.microsoft.com/kb/820729， 后来综合分析了下，这个响应时间设置得太小，那么也会影响正常的连接过于频繁，岂不是也会引起这个问题，另外想起来，前段日子由于一个站的mdb数据库过 于庞大，就把它的响应时间调到了几十秒，会不会这方面也有影响呢？想到此，就把这个asp站的响应时间调到了240秒，把那个dz论坛的响应时间也由以前 的30秒调到了600秒，然后再把其他所有网站的响应时间都调到了240秒，之后，重启iis，观察。观察了半个多小时，发现iis再没有内存占用不正常 退出的现象，也没有内存突然增大的情况，错误日志的增涨一会功夫也看不出来，把所有日志删除了以后，明天再观察下，看日志情况如何？
另外，这个httperr日志很容易引起系统盘空间占尽，因此，要针对此情况，定期清理，还有，很多站的问题，都可以从这个日志里面分析出来，比如dz论坛的有些SQL语句查询和插件的语句写得不够优化和严谨，这个由于代码道行不够，只有呼吁了，好像尽呼吁也没用，郁闷。
上述做法，也不一定能够真正的解决问题，看当前的现象来反映，也只是缓解这个问题。
做个事，不容易啊！
还是昨天发现的那个问题，今天发现dz论坛又不能访问了，然后访问了一下其他应用程序池的站，访问正常，说明dz论坛所在的应用程序池，估计又死了。看来，昨天的解决方案，不妥。
登 陆服务器，果然，该应用程序池，已经连着有三个了，前两个还没有正常关闭，第三个也已经二百多M了，吓人；马上结束掉这几个应用程序池，然后到iis管理 里面，停止这个应用程序池，之后直接到httperr目录里面，查看iis错误日志，马上又发现了很多“虚拟股市”引起的日志错误，大篇的，很长；开启应 用程序池，到后台关闭掉插件“虚拟股市”，然后观察了下应用程序池，发现比较平稳，论坛反应速度比较快，比较正常，cpu虽然还是有些高，但算正常。
一边观察服务器的状态，一边再次查看了下最近的错误日志，发现有很多503的错误，搜索一下网络吧；网上有人发贴说可能与应用程序池的进程回收设置有关，建议把应用程序池的回收属性页的所有回收选项都禁用，理由是如果没有发现内存泄漏，线程刮起等现象的话应该就不需要设置进程回收。
现 在不确定503错误到底是不是和进程回收有关系，如果禁用进程回收设置会不会缓解这个问题，会不会引起更严重的错误。就是如果一个web应用程序用着用着 就莫名其妙的出错了，而查不到原因，而重启IIS或者重启应用程序池就缓解了，这时候就设置一下达到一定条件进行进程回收，但只是暂时的解决方案，最终应 该找到原因并修复应用程序。
IIS帮助里也明确说明了设置进程回收的场景，而且说重叠回收中不会断掉tcp链接，会自动把请求平滑过度到新进程中，也就是这个过程中不会引起服务不可用，也就是503错误。
所以我也比较倾向于关掉进程回收选项。
为应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程ID是,IIS6.0经常假死（里面的观点不要无理由地打开回收工作进程和使用工作进程池。一般理由通常是有不明原因的内存泄露、线程挂起等）
http://hi.baidu.com/nayinian/blog/item/468c900fce94dcecab6457f7.html
为应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程ID是,IIS6.0经常假死，经常有这样的提示:
事件类型: 警告
事件来源: W3SVC
事件种类: 无
事件 ID: 1013
日期: 2004-7-26
事件: 16:01:51
用户: N/A
计算机: COM-NET
描述:
为应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程 ID 是 '2552'。
有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。
相信这是由于不正确地设置了回收进程导致，建议关闭下列进程回收设置：
回收工作进程(分钟)：1200
回收工作进程(请求数目)：10000
启用CPU监视，最大CPU使用率：90%
这三种情况，恰恰我都设置了。依次所说，干脆把这有关回收的项目，全部关闭了，由服务器自已管理应用程序池的内存应用状况。
由 于设定了进程自动回收，而当每达到10000次点击，或CPU超过100%,就会强行回收application，导致客户端会出现Sevice Unavailable的错误。(实际上10000次点击，访问量一般的网站，几分钟就够了。) 建议启用计数器日志来监视CPU利用率和ASP.NET的指标，可以帮助你定位每5~10分钟出现一次是否是上述原因导致。
另外，不要无理由地打开回收工作进程和使用工作进程池。一般理由通常是有不明原因的内存泄露、线程挂起等
回收工作进程相关说明（win2003安装iis在ie里键入下面的地址，里面介绍了启用进程回收的时机及重叠回收的概念）
mk:@MSITStore:C:\WINDOWS\Help\iismmc.chm::/htm/ca_recycwrkrprocess.htm
错误定义：503：“服务不可用”错误是一个非自定义的错误，该错误表示服务器当前无法处理该请求。
原因：
1、管理员可能关闭应用程序池以执行维护。
2、当请求到达时应用程序池队列已满。
3、应用程序池标识没有使用预定义账户：网络服务，而自己配置了标识，但是配置的这个用户不属于IIS_WPG组
4、应用程序池启用了CPU监视，并且设置了CPU利用率超过一定百分比关闭应用程序池，而开发人员写的服务端页面（.asp,.aspx）执行效率不高，会引起CPU的长时间占用，最终达到设置的百分比，从而引起应用程序池关闭
5、应用程序池的性能选项卡的请求队列限制所填的数值太小，默认为1000，可修改成一个更大的值，比如说4500.
6、web.config的system.web/httpRuntime节点的appRequestQueueLimit属性设置的值太低。
排查思路：
1、 先检查C:\WINDOWS\system32\LogFiles\HTTPERR\httperr1.log，看里面有没有503错误，503错误是不 会记录到C:\WINDOWS\system32\LogFiles\W3SVC1下的，如果503那一行有AppShutdown字样，肯能是由于 CPU占用率太高导致自动关闭应用程序池。如果是AppOffline可能是由于应用程序标识出错引起的，如果是Disabled可能是由于管理员手工关 闭应用程序池引起的。根据这些信息然后再采取响应措施。
2、根据原因5和原因6来设置更大的请求队列数目。
3、禁用所有应用程序池回收选项。
4、添加ASP.NET\Requests Current，ASP.NET\Requests Queued两个计数器，查看IIS的请求数和队列数。
更多内容，可至此查询：
相关链接：
TechNet V播：HTTP503故障排除（里面提到的可能性不打）
http://www.microsoft.com/china/technet/vcast/live/episode.aspx?newsID=class01_022
\\CXZ.amigo.bjmcc.net\input\503.wmv
IIS 状态代码(里面提到iis状态码及可能原因，其中包括503)
http://support.microsoft.com/kb/318380
如果 AppPoolQueueLength 值是否太低 " HTTP 503 服务不可用 " 错误消息（如果网站访问量比较大也许是这个原因）
http://support.microsoft.com/kb/816995/zh-cn
http://support.microsoft.com/kb/816995/en
FIX： ASP.NET 队列请求太多（该问题是asp.net 1.0的bug，已经有hotfix修复）
http://support.microsoft.com/kb/822148/zh-cn
http://support.microsoft.com/kb/822148/en
<httpRuntime appRequestQueueLimit> 元素（文中提到如何通过配置文件来设置应用程序请求的最大数目）
http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/cpgenref/html/gngrfhttpruntimesection.asp
客户端请求收到“503：服务不可用”错误（阐述503定义、可能原因及问题排查）
http://technet2.microsoft.com/WindowsServer/zh-CHS/Library/
IIS 6.0入门及进阶webcast（有IIS排错系列）
https://www.microsoft.com/china/technet/webcasts/class/iis.mspx
大家是不是也常遇到服务器不可用啊?Service Unavailable（博客园的一群人讨论503的原因及应该采取的措施）
http://www.cnblogs.com/birdshome/archive/
为应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程ID是,IIS6.0经常假死（里面的观点不要无理由地打开回收工作进程和使用工作进程池。一般理由通常是有不明原因的内存泄露、线程挂起等）
http://hi.baidu.com/nayinian/blog/item/
回收工作进程相关说明（win2003安装iis在ie里键入下面的地址，里面介绍了启用进程回收的时机及重叠回收的概念）
mk:@MSITStore:C:\WINDOWS\Help\iismmc.chm::/htm/ca_recycwrkrprocess.htm
上述内容摘自：http://www.cnblogs.com/onlytiancai/archive/2007/06/03/769309.html
在IIS 6.0中，记录日志的功能已经改为由http.sys实现，http.sys在内核模式下运行。这一改进加快了日志写入速度，同时避免了多个工作进程争用 同一日志文件。某些特殊的情况下，http.sys会遇到错误，这时它应该但却不能将日志信息写入Web网站的日志，例如，工作进程正在被回收，禁止 http.sys处理用户请求，或者用户试图连接到服务器，但请求中只提供了IIS所需信息的一部分。如果出现这类情况，http.sys将把事件写入一 个新的日志文件httperr.log。
在排解故障、优化IIS 6.0的过程中，httperr.log日志文件是十分重要的。默认情况下，httperr.log文件保存在\system32\logfiles目 录，但可以修改，修改方法是找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP \Parameters注册子键，在它下面添加一个名为ErrorLoggingDir的字符串值，在ErrorLoggingDir中设置保存日志文件 的完整路径。在httperr.log日志文件中可以找到的信息包括：所有的503（服务不可用）错误，空闲连接超时，解析URL时出现的各种错误，最后 10个提交给失败的应用程序池的请求。
IIS 6.0还拥有一种称为二进制日志的功能，启用 这个功能后，IIS 6.0将把Web网站的所有日志信息写入一个二进制格式的日志文件，日志文件的扩展名是.ibl。要启用二进制日志功能，只要把配置文件的 W3SVCC/CentralBinaryLoggingEnabled条目设置成ture（1）即可。对于ISP来说，这个功能应该非常有用。ISP的 每台机器上可能有1000甚至更多的Web网站，如果每个Web网站每天生成一个日志文件，日志文件的总数很快会达到一个天文数字。微软最近发布的Log Parser 2.2工具能够读取二进制日志文件并生成报告，这个工具可以Log Parser 的最新版本（2.2 版）下载。Log Parser 2.2还能够读取前面介绍的httperr.log文件并生成报告。如果这个直接下载链接不行，就还是从上面这个链接开始下吧。http://www.microsoft.com/downloads/info.aspx?na=90&p=&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=890cd06b-abf8-4c25-91b2-f8d975cf8c07&u=http%3a%2f%2fdownload.microsoft.com%2fdownload%2ff%2ff%2f1%2fff1819f9-f702-48a5-bbc7-c9656bc74de8%2fLogParser.msi
从很久以前开始，IIS就允许指定本地服务器上保存日志文件的目录了。不过，虽然IIS 5.0和IIS 4.0的IIS管理器允许在指定日志文件路径的时候输入一个远程服务器的通用命名规范（UNC）的路径，但Web服务器实际上不会把日志保存到远程服务 器。只有IIS 6.0才真正支持日志文件路径的UNC路径名。
Log Parser 确实是一种非常酷的小实用工具，它解决了一些非常棘手的脚本启动问题。我们仍然不知道分析 SQL Server 日志有什么用，但是我们知道 Log Parser 的最新版本（2.2 版）能做以下事情：
• 搜索事件日志，快速找到并报告所关注的事件。
• 搜索文件系统，快速找到并报告所关注的文件和文件夹。
• 搜索 Active Directory，快速找到并报告所关注的对象。
• 搜索各种各样的日志文件。例如，Log Parser 能够搜索使用 W3C 扩展日志文件格式的日志。使用此格式的日志包括：个人防火墙日志；Microsoft Internet Security and Acceleration (ISA) Server 日志；Windows Media Services 日志；Exchange 跟踪日志；简单邮件传输协议 (SMTP) 日志文件。
• 快速而轻松地搜索 Internet 信息服务 (IIS) 日志、Netmon 捕获文件、注册表等多种文件。
这 些功能还占不到它的全部功能的一半呢。Log Parser 使用一种真正的 SQL 查询语言，这意味着您可以执行聚合查询。想知道您的事件日志中的各种事件 ID 类型的数量（三十七个事件 100、四十三个事件 101、十四个事件 102）吗？没问题，Log Parser 能够胜任这项工作。当然，它还可以胜任很多很多其他工作。您可以使用一个 SQL 命令（例如“ORDER BY”）来以您需要的任何方式对返回数据进行排序，也可以使用“TOP”来仅返回若干最“如何如何”的记录（例如，您的硬盘上的 10 个最大的文件）。您可以从命令提示符下运行 Log Parser 2.2，也可以将其作为一个可编写脚本的 COM 对象 (MSUtil.LogQuery) 进行调用。
更多详细的功能示例我就不多说了，我要去安装测试去了，有意的到这个阿sir这里慢慢欣赏吧：有了 Log（即 Log Parser）就万事大吉了http://hi.baidu.com/totaobao/blog/item/c922a3649e3750f1f636542c.html
log parser2.2的详细情况及如何动作等功能，也可关注微软专贴：http://www.microsoft.com/china/technet/community/columns/profwin/pw0505.mspx
