使用 Mdbg 的 ASP.NET 基于 Web 的堆栈转储工具？
MySpace 首席系统架构师 Dan Farino 提供了精彩的 演示 .com，展示了一个基于 Web 的堆栈转储工具，该工具对给定进程中运行的所有线程进行编目（它们正在做什么、执行了多长时间等）。
他们的技术也总结在 highscalability.com：
- PerfCollector。
集中 通过收集性能数据 UDP。比 Windows 更可靠 允许任何客户端连接并查看 统计数据。 - 基于网络的堆栈转储工具。
可以右键单击有问题的服务器 并获取 .Net 的堆栈转储 托管线程。以前必须RDC 进入系统并附加调试器和 1/2 后得到答案。慢的， 不可扩展且乏味。不只是一个 堆栈转储，提供了很多上下文 关于线程正在做什么。 故障排除更加容易，因为您 可以看到 90 个线程被阻塞 数据库，因此数据库可能已关闭。 - Web 基础堆转储工具。
转储全部 内存分配。非常有用 开发商。节省时间 手。 • 分析器。跟踪请求 从开始到结束并产生 报告。查看 URL、方法、状态、 一切对你有帮助的事情 识别缓慢的请求。看着 锁争用，有很多 抛出异常，任何事情 这可能很有趣。很轻 重量。它在一个盒子上运行 每个 VIP（100 个服务器组） 生产。每 10 个线程采样 1 个线程 秒。始终追踪 背景。
问题是：为 ASP.NET 构建基于 Web 的堆栈转储工具需要哪些工具？为了方便起见，我们假设目标 AppDomain 中托管有一个 *.aspx，能够输出所有托管的内容该过程中的调用堆栈就足够了。
有几篇文章介绍了 Mdbg（完全用 C#/IL 编写的托管代码的调试器，开始随 CLR 2 SDK 一起提供）和通常可以找到的 mdbgcore 程序集的使用在 C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin 中：
- http://dotnetdebug.net/2005/11/09/exceptiondbg-v01-debug-your-exceptions/
- http://blogs.msdn.com/jmstall/archive/tags/MDbg/default.aspx
- http://blogs.msdn.com/vijaysk /archive/2009/11/04/asp-net-debugger-extension-for-iis-7.aspx
解决方案是否只需引用此程序集即可产生所需的输出？ “列出所有托管调用堆栈”操作会对为生产流量提供服务的运行进程产生什么影响？
There is a great presentation by Dan Farino, Chief Systems Architect at MySpace.com, showcasing a web-based stack dump tool that catalogues all threads running in a given process (what they're doing, how long they've been executing, etc.)
Their techniques are also summarized on highscalability.com:
- PerfCollector.
Centralized
collection of performance data via
UDP. More reliable than Windows and
allows any client to connect and see
stats. - Web Based Stack Dump Tool.
Can right-click on a problem server
and get stack dump of the .Net
managed threads. Used to have to RDC
into system and attach a debugger and
1/2 later get an answer. Slow,
nonscalable, and tedious. Not just a
stack dump, gives a lot of context
about what the thread is doing.
Troubleshooting is easier because you
can see 90 threads are blocked on a
database so the database may be down. - Web Base Heap Dump Tool.
Dumps all
memory allocations. Very useful for
developers. Save hours of doing it by
hand. • Profiler. Traces a request
from start to finish and produces a
report. See URL, methods, status,
everything that will help you
identify a slow request. Looks at
lock contentions, are a lot of
exceptions being thrown, anything
that might be interesting. Very light
weight. It's running on one box in
every VIP (group of 100 servers) in
production. Samples 1 thread every 10
seconds. Always tracing in
background.
The question is: what tools are required to build a web-based stack dump tool for ASP.NET? For convenience, let's assume that an *.aspx hosted in the target AppDomain, able to output all managed call stacks in that process, is sufficient.
There are a few posts that cover the use of Mdbg (debugger for managed code written entirely in C#/IL that started shipping with CLR 2 SDK) and the mdbgcore assembly typically found in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin:
- http://dotnetdebug.net/2005/11/09/exceptiondbg-v01-debug-your-exceptions/
- http://blogs.msdn.com/jmstall/archive/tags/MDbg/default.aspx
- http://blogs.msdn.com/vijaysk/archive/2009/11/04/asp-net-debugger-extension-for-iis-7.aspx
Would a solution simply reference this assembly to produce the desired output? What impact would a "list all managed call-stacks" operation have on the running process that's servicing production traffic?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我相信 .Net 的分析 API 是正确的选择。
请查看 Google 代码上的 SlimTune 项目，获取包含源代码的实时示例可以检查如何适应和改进以在Asp.NET场景中工作。
问候
马西莫
I believe the profiling API of .Net are the way to go.
Look at the SlimTune project on Google Code to have a live sample, with sources, that you can check how to adapt and improve to work in a Asp.NET scenario.
Regards
Massimo
使用 .Net 的分析 API，您必须停止服务器，这会占用大量 CPU（但它使您可以完全控制所有调用的方法）。
我认为最“轻松”的解决方案是使用 MDbg 来完成此操作，我编写了一个非常小但有用的小应用程序，名为 StackDump 执行以下操作：
1) 调试器停止应用程序并生成为该进程运行的所有 CLR 堆栈的列表。
2) 再次启动应用程序。
此操作是一个快速操作，可以（也许）在运行的生产服务器上执行，而生产代码无需更改。
只需 80 行 .Net 代码即可管理此操作。我已在 Codeplex 上发布了源代码。
With the profiling API of .Net you have to stop the server and it takes a lot CPU (but it gives you full control over all called methods).
I think the most “light way” solution is to doing this with MDbg, I put together a very small but useful little app called StackDump that does the following:
1) The debugger stops the application and generates a list of all CLR stacks running for the process.
2) The application is started again.
This operation is a quick operation and can (maybe) be executed on a running production server with unchanged production code.
It just 80 lines of .Net code to manage this. I have published the source code on Codeplex.