MA 1.1存在巨大的内存问题 [英] Huge memory issue with MA 1.1
问题描述
大家好，
我今天试图运行MA 1.1，并遇到了巨大的内存泄漏。 我在Windows 7框上运行了本地实时跟踪，并将过滤器设置为LDAP。 大约30秒后，整个机器开始冻结。 根据任务管理器，MessageAnalyzer.exe
使用了5,101,712 K的内存和96％的CPU。 我无法通过用户界面停止跟踪，不得不通过任务管理器将其删除。 之后Windows立即恢复正常运行。
I tried to run MA 1.1 today, and encountered a HUGE memory leak. I ran a local live trace on my Windows 7 box and set the filter to LDAP. After about 30 seconds, the whole machine started freezing. According to Task Manager, MessageAnalyzer.exe was using 5,101,712 K of memory, and 96% of the CPU. I could not stop the trace via the UI, and had to kill it via Task Manager. Windows resumed normal operation immediately afterwards.
是否有解决方法或修复此问题？ 我更喜欢使用MA而不是竞争对手，但显然没有这种行为。
Is there any workaround or fix for this? I'd prefer to use MA instead of the competitors, but obviously not with this behavior.
谢谢，
Jerry
Jerry Dixon
Jerry Dixon
推荐答案
我不确定，但也许可能是因为这种类型您正在捕获的LDAP流量。实际上，获取跟踪可能很有用，因此我们可以进行调查。使用LDAP，我们对搜索请求进行分组，如果有很多不完整的请求，这可能会导致
看起来像内存泄漏。 我们可以通过以下两种方式之一解决此问题。\\ n 然后我们可以尝试了解这个问题。
I'm not certain, but perhaps it could be due to the type of LDAP traffic you are capturing. In fact it might be useful to get a trace so we can investigate. With LDAP we group search requests, and if there are a lot of incomplete ones, this could cause what looks like a memory leak. We can work around this problem in one of two ways to get the capture. And then we can try to understand the issue.
1. 我们可以使用UI捕获并告诉它不要解析任何内容。 生成的捕获将是原始ETW消息，但随后我们可以重新加载并验证内存使用情况。 如果这样可行，我们可以使用其他一些方法（例如按时间限制
或不同的解析级别来显示LDAP）。 为此，您需要进行客户实时会话（文件 - >新会话），然后选择实时会话按钮。 在底部有一个解析级别下拉列表，您可以将其设置为"高性能
捕获而不解析"。
1. We can capture using a the UI and tell it not to parse anything. The resulting capture will be raw ETW messages, but then we can reload and verify the memory usage. If this works, we can use some other methods (like limiting by time or a different parsing level to display LDAP). To do this, you need to do a customer Live Session (File -> New Session), then select the Live Session button. At the bottom there is a parsing level drop down which you can set to "High Performance Capture without Parsing".
2. 另一种方法是使用PowerShell捕获，并保存为未解析的。 这导致在捕获时不进行解析，并且在性能成为问题时捕获流量的最佳方式。 有关详细信息，请参阅此博客：
http://blogs.technet.com/b/messageanalyzer/archive/2013/10/29/using-powershell-to-automate-tracing.aspx。
2. Another method is to use PowerShell to capture, and saved as unparsed. This results in no parsing while capturing and is the best way to capture traffic when performance is an issue. See this blog for more information: http://blogs.technet.com/b/messageanalyzer/archive/2013/10/29/using-powershell-to-automate-tracing.aspx.
如果这样可行，那么我们应该尝试加载生成的跟踪并查看内存使用情况是否再次发生。 让我知道结果，我们可以在这些调查结果之后采取下一步措施。
If this works, then we should try to load the resulting trace and see if the memory usage happens again. Let me know the result and we can take the next step after those findings.
谢谢，
保罗
这篇关于MA 1.1存在巨大的内存问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
