win服务器

关注公众号 jb51net

关闭
首页 > 网站技巧 > 服务器 > win服务器 > IIS监控指标和调试

中间件IIS监控指标、设置和Windbg|Mex调试分析

投稿:yin

在IIS Web服务器中,worker processe处理Web请求并提供响应,一台服务器同时运行多个进程,每个worker processe都属于一个应用程序池,且与不同池关联的工作进程不共享该池资源,IIS监控主要针对会话、事务、缓存、内存、线程池等进行监控

IIS 是由微软公司提供的基于运行 Microsoft Windows 的互联网基本服务,同时也是一种Web(网页)服务组件,其中包括 Web 服务器、FTP 服务器、NNTP 服务器和 SMTP 服务器,分别用于网页浏览、文件传输、新闻服务和邮件发送等方面,它使得在网络(包括互联网和局域网) 上发布信息成了一件很容易的事。

IIS 具有一些既有趣又强大的功能,我们打开文档,会发现一些编辑文字或者编辑文档的界面,会有搜索的功能,这就是 IIS 的作用之一。在一些小地方,或者一些细节之处,IIS具有极其丰富有有作用的细节能力,而编辑文字或者文档中含有搜索功能,也是 IIS 细节的体现。

在IIS Web服务器中,worker processe处理Web请求并提供响应。一台服务器同时运行多个进程。每个worker processe都属于一个应用程序池,且与不同池关联的工作进程不共享该池资源。即使IIS服务器和应用程序是两个单独的实体,但仍有一些指标与这两个指标关联。与worker processe相关的指标,例如应用程序池和响应时间,对于维持IIS服务器和应用程序的健康状况健康状况至关重要。

IIS监控指标

在IIS应用程序中要监控的关键性能指标(KPI):

网站统计指标:可用性、响应时间、连接状态、字节传输统计

应用程序池统计信息

应用程序性能指标:数据库事务、响应时间、错误与例外 

IIS服务器监控  

为了避免IIS服务器停机,跟踪服务器数据指标(例如应用程序池统计信息,资源消耗和响应时间)也很重要。

关键性能计数器指标

a. Web服务(W3SVC)性能计数器

b. ASP.NET性能计数器

c. ASP.NET应用程序性能计数器

d. 内存性能计数器

e. CPU性能计数器

设置最佳实践

a. 应用程序池配置

b. 输出缓存

c. 静态内容缓存

d. 压缩

e. 监控和日志记录

f. 安全设置

示例:

假设您发现IIS服务器上的“每秒请求数(Requests/sec)”持续很高。这可能表明网站流量增大或者有性能瓶颈出现。首先,您应该检查服务器的CPU和内存使用情况,如果资源使用正常,可能需要查看具体的应用程序代码或数据库查询是否有优化空间。如果资源使用率很高,您可能需要考虑扩展硬件资源或者通过负载均衡将流量分散到多个服务器。

另一个例子,如果“请求排队数(Requests Queued)”持续增加,这可能意味着应用程序池的最大工作进程数设置得过低,或者应用程序代码处理请求的效率不高。针对这种情况,您可以提高最大工作进程数,同时检查和优化代码以更高效地处理请求。

通过监控这些关键性能计数器并采取相应的最佳实践,您可以确保IIS服务器的性能得到最优化。

关于IIS请求队列

IIS请求队列是在应用程序池中处理请求之前,临时存放请求的地方。当请求的处理速率低于请求到达的速率时,请求就会在队列中堆积。如果队列中的请求数量过多,可能会导致用户体验变差,甚至请求超时。

监控请求队列

要监控IIS请求队列,可以使用Windows性能监视器(Performance Monitor)中的以下性能计数器:

优化请求队列设置

优化IIS请求队列设置的目标是减少请求在队列中的等待时间,确保请求能够快速被处理。这通常可以通过以下方法实现:

示例配置

这是一个修改应用程序池队列长度的示例:

请注意,调整队列长度并不总是解决问题的最佳方式,有时候需要更全面的方法来分析和优化整个应用程序和服务器的性能。

使用windbg分析IIS请求队列

使用WinDbg (Windows Debugger) 分析IIS请求队列通常涉及到对IIS工作进程(w3wp.exe)的内存转储(dump)文件进行分析。这种分析可以帮助你确定在特定时间点上请求的状态,找出请求积压的原因,并且识别性能瓶颈。

以下是使用WinDbg分析IIS请求队列的一般步骤:

1. 获取内存转储

在分析之前,你需要首先获取IIS工作进程的内存转储。这可以通过任务管理器、IIS管理器或专用的转储工具来完成。例如,你可以使用如下命令通过procdump工具获取内存转储:

procdump -ma <PID> -o <output_path>

这里 <PID> 是IIS工作进程w3wp.exe的进程ID,而 <output_path> 是你想要保存转储文件的路径。

2. 设置符号路径

在WinDbg中,设置正确的符号路径(symbol path)是很重要的,因为它允许调试器正确解析内存转储中的地址。你可以将Microsoft的符号服务器设置为符号路径:

SRV*your_local_symbol_cache*https://msdl.microsoft.com/download/symbols

在WinDbg中,你可以通过.symfix命令自动设置符号服务器,或者使用.sympath命令手动设置路径。

3. 加载内存转储

在WinDbg中打开内存转储文件。通常是通过 File > Open Crash Dump 菜单选项或者使用命令行参数启动WinDbg。

4. 分析请求队列

一旦加载了内存转储,你可以使用各种WinDbg命令来分析请求队列。一些有用的命令包括:

5. 查找请求相关的对象

在.NET应用程序中,你可能需要查找与HTTP请求相关的对象,比如HttpContext。你可以使用!dumpheap -type HttpContext命令来找到所有HttpContext对象的内存地址,然后用!do <address>命令来检查每个对象的详细信息。

6. 分析特定请求

如果你能够识别出具体的请求对象,你可以进一步分析这些对象,找出为何请求没有得到及时处理。这可能涉及到查看请求的状态、执行的代码路径以及任何可能的资源锁定情况。

7. 寻找死锁和资源争用

使用!syncblk命令可以查找.NET应用程序中的锁定情况,这有助于识别死锁或资源争用的问题。

注意事项

WinDbg的分析能为你提供有关请求处理状态的深入见解,但它不是实时监控工具。对于实时监控IIS请求队列的情况,你可能需要依赖性能计数器或者专业的监控软件。

Mex(Managed Execution Environment)是一个用于WinDbg的扩展插件,专门设计用来调试.NET应用程序。它提供了一系列的命令来帮助分析.NET应用程序的内存转储,包括那些托管在IIS中的ASP.NET应用程序。使用Mex插件可以帮助你更容易地分析IIS请求队列和相关的托管对象。

如何使用Mex插件分析IIS请求队列:

1. 安装Mex插件

首先,你需要确保Mex插件已经被安装并配置到WinDbg中。通常,这意味着你需要下载Mex插件,并将其复制到WinDbg的扩展目录中,然后在WinDbg中使用.load命令来加载它。

2. 获取内存转储

与使用WinDbg直接分析类似,你首先需要获取IIS工作进程(w3wp.exe)的内存转储。你可以使用任务管理器、IIS管理器或工具如procdump来完成这个步骤。

3. 使用WinDbg打开内存转储

在WinDbg中打开内存转储文件,通常是通过 File > Open Crash Dump 菜单选项。

4. 加载Mex插件

在WinDbg中,通过.load命令加载Mex扩展:

.load <path_to_mex.dll>

5. 设置符号路径

确保设置了正确的符号路径,这样WinDbg才能正确解析转储中的符号信息。

6. 分析请求队列

使用Mex提供的特殊命令来分析请求队列。Mex为.NET应用程序提供了一些有用的命令,如:

7. 深入分析特定请求

如果你发现队列中有特定的请求被阻塞,你可以使用Mex命令来检查这些请求的详细信息,比如调用堆栈、关联的资源和锁状态等。

示例:

例如,如果你想看所有当前的ASP.NET请求,可以使用以下Mex命令:

!mex.requests

这个命令会输出当前所有请求的列表,包括它们的状态、正在处理它们的线程ID等信息。

注意事项

使用Mex插件可以大幅简化.NET应用程序的内存转储分析过程,特别是对于IIS托管的ASP.NET应用程序。它可以帮助你更快地识别问题,从而优化IIS请求队列的性能。

到此这篇关于中间件IIS监控指标、设置和Windbg|Mex调试分析的文章就介绍到这了,更多相关IIS监控指标和调试内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:
阅读全文