如何在 asp.net 应用程序中找到 i/o 瓶颈答案

【问题标题】：How to find i/o bottleneck within asp.net app如何在 asp.net 应用程序中找到 i/o 瓶颈
【发布时间】：2013-02-25 01:08:03
【问题描述】：

我们有一个产生大量 I/O 的高流量网站。在 10 分钟内，它已读取超过 10 GB 的数据（在任务管理器中看到有问题的 w3wp）。对于内存和应用程序挂起，我一直在成功使用 WinDbg。但我不知道如何在负责最高 I/O 的进程中找到对象/方法。

这可能吗？

编辑问题是：有没有办法在 .NET 程序集中分析 I/O 操作，比如：按最高磁盘 I/O 排序的线程列表（或类似的东西可以帮助我在哪里查看）

【问题讨论】：

您知道它可能在您的代码中发生的位置，还是您完全失明？
我不知道，浏览了所有代码几次（这是一个相当大的站点，有很多功能）。可以上传和发布图片，但每月数据量约为 10GB。
您是否偶然在应用程序中处理这些图像？
不，使用单独的无 cookie 域用于具有不同应用程序池的域
你必须先做一些计算。您的应用程序的平均页面大小是多少？你每分钟有多少用户？有了这个，你可以计算你的应用程序的平均 IO，看看你的流量与页面大小是否正常。如果正常，那么您可能需要扩展您的硬件（使用 SDD 或 RAID 而不是简单的 HDD）或更改代码中的某些内容。仅凭这些信息很难判断问题出在哪里，但我希望这会有所帮助你

标签： asp.net iis windbg performance

【解决方案1】：

ANTS Performance Profiler

我已经使用这个工具取得了巨大的成功 - 处理在 5 到 10 分钟内找到导致高容量网络场上约 512GB 内存被占用的特定指令。听起来和你的情况很相似。

现在，现实一点 - 它不会神奇地解决您的问题。它仍然需要大量的设置、彻底的分析和侦查工作。但是这个工具确实把问题从“几乎无法解决”变成了“几天之内就能解决”。

更新：

正如我在 cmets 中提到的（并且 Ben Emmett 回应），我们可以使用 ANTS 来监控内存、文件系统句柄 - 几乎任何资源消耗，并深入调用堆栈以查看特定例程的效果。

【讨论】：

您能否详细说明如何处理蚂蚁？你在使用内存分析器吗？与windbg相比，我发现它有点限制。
@Elger 从最外面的可疑例程开始，我们可以观察在该例程中积累了多少内存、FS 句柄等 - 并开始深入研究更深层次的例程，同时看到资源积累保持相对平稳- 这意味着我们正在解决问题。
但内存消耗实际上并不那么令人担忧（繁忙时最大 400 mb，64 位应用程序通常约为 275 mb）。在您的情况下，512GB 内存是什么意思？
@Elger 在我的情况下是内存消耗，但您可以监控任何类型的资源消耗。
ANTS Performance Profiler 还记录文件系统访问，这听起来对您的情况很有用：red-gate.com/supportcenter/Content/ANTS_Performance_Profiler/…

【解决方案2】：

我想出了这个工具AppDynamics Lite，它以可视化的方式显示您的应用程序调用成本和性能。它可能会帮助您找出哪些函数正在执行最昂贵的 IO 操作。

引用;

通过响应时间、吞吐量、异常率和垃圾收集时间等关键指标以及 CPU、内存和磁盘 I/O 等关键系统资源了解 CLR 的运行状况。

值得一试，因为它可以试用/免费 30 天。希望能帮助到你。 Ps：我与 AppDynamics 没有任何关系。

【讨论】：

【解决方案3】：

您可以使用 Windows 8 中的（免费）Windows Performance Toolkit，它也可以在 Windows Vista 及更高版本上运行。在那里，您可以打开系统范围的分析，以立即查看所有进程中发生了什么。无需仪器。只需重新启动一次即可设置由 WPRUI.exe 自动完成的神秘注册表项。

使用 XPerf，您可以启用 IO Init 堆栈遍历，以便为每个启动的 IO 获取一个调用堆栈。唯一的问题是 64 位进程的堆栈将被破坏，这意味着您只会看到代码的 BCL 方法上方的第一个方法，因为操作系统的堆栈遍历功能中存在 Windows 7 错误。

一种解决方法是对您的程序集进行 Ngen 或迁移到 Server 2012 或切换到 x86 进行分析以查看更深入的调用堆栈。

您将看到所有文件 IO 和 CPU 活动，即使没有任何调用堆栈和文件名以及硬盘使用时间。这应该会给你很好的信息，你的应用程序的哪一部分导致了磁盘 IO。即使没有完整的堆栈，您也应该能够从部分调用堆栈中查明您的问题。

该工具比任何市售的分析器都能为您提供更多洞察力，但您需要学习如何使用它。由于调用堆栈不会在您的代码或用户模式下结束，而是在内核中，您还可以确定是否例如病毒扫描程序导致严重的 IO 延迟。但是你需要知道你的处理器是如何工作的。这个工具集最初是针对内核开发者的，它解释了为什么你会看到这么多无用的列。

在下图中，您可以看到文件 IO 和 CPU 消耗堆叠在一起。当您在磁盘 IO 图表中选择高 IO 文件时，它将在 CPU 消耗中突出显示所有相关调用堆栈，这些调用堆栈在 IO 处于活动状态时同时进行。通过这种方式，您可以直接从 IO 导航到可能被阻塞的线程。

【讨论】：

哇，非常感谢您的洞察力。我不知道这存在。我试试看。