在对 ASP.NET 应用程序进行负载测试时，我们发现页面在高负载下需要 20-30 秒。
我们怀疑这是因为页面正在等待数据库调用或 Web 服务。
是否有特定的性能计数器可以识别 Web 服务器上的此类瓶颈？CPU、内存和磁盘均正常。
或者我们必须使用 perfmon 以外的工具来追踪这个瓶颈？
答案1
如果您怀疑某个特定应用程序或服务导致内存泄漏，请使用以下计数器调查应用程序的内存使用情况：
Memory\Available Bytes reports available bytes; its value tends to fall during a memory leak.
Memory\Committed Bytes reports the private bytes committed to processes; its value tends to rise during a memory leak.
Process\Private Bytes reports bytes allocated exclusively for a specific process; its value tends to rise for a leaking process.
Process\Working Set reports the shared and private bytes allocated to a process; its value tends to rise for a leaking process.
Process\Page Faults/sec reports the total number of faults (hard and soft faults) caused by a process; its value tends to rise for a leaking process.
Process\Page File Bytes reports the size of the paging file; its value tends to rise during a memory leak.
Process\Handle Count reports the number of handles that an application opened for objects it creates. Handles are used by programs to identify resources they must access. The value of this counter tends to rise during a memory leak; however, you cannot rule out a leak simply because this counter's value is stable.
内存泄漏和非分页池
尽管任何泄漏都是严重的，但当内存泄漏涉及非分页池时，尤其令人担忧。许多系统服务从非分页池分配内存，因为它们在处理中断时需要引用它，并且当时不能发生页面错误。要确定泄漏是否影响非分页池，请在监视中包含以下计数器：
Memory\Pool Nonpaged Bytes
Memory\Pool Nonpaged Allocs
Process\Pool Nonpaged Bytes
如何识别：泄漏的应用程序不断请求更多内存。它的特点是进程/页面文件字节数以与系统已提交字节数相同的速率增加；即所有内存提交都归因于一个进程。可用字节数稳步减少，直到系统将某些内容调出页面，然后虚拟字节数增加以腾出更多可用字节空间。泄漏应用程序的工作集实际上在其部分内容被调出页面时减少。请注意，随着可用字节数的减少，页面错误/秒如何增加。
Windows 资源工具包中包含一个名为 LeakyApp.exe 的示例程序。该程序的典型缺陷是不断分配越来越多的内存。