为什么 WMI 查询有时这么慢？
我正在 .Net 中使用 System.Management 命名空间对远程服务器执行各种 WMI 查询。在我的日志中，我可以看到有时查询需要 30 或 40 秒才能完成，而其他时候查询会在不到一秒的时间内完成。
当我看到这些缓慢的查询时，我尝试使用 wbemtest 连接到该框，但它总是快速连接并执行查询。
有什么想法、指点、建议吗？
在反射器中查看 System.Management.ManagementScope 时，我确实注意到它似乎泄漏了 IWbemServices 指针。看起来这是一个 COM 接口，需要对其调用 Release (Marshal.ReleaseComObject())。我不确定这是否相关。在该过程的生命周期中，我确实连接到许多不同的服务器。
I am using System.Management namespace in a .Net to execute various WMI queries against a remote server. In my logs I can see that sometimes the queries take 30 or 40 seconds to complete while other times the queries complete in less than a second.
When I see these slow queries, I try to connect to the box using wbemtest, but it always connects and executes the query quickly.
Any ideas, pointers, suggestions?
I did notice when looking at System.Management.ManagementScope in reflector that it seems to leak a IWbemServices pointer. It looks like this is a COM Interface that needs to have Release called on it (Marshal.ReleaseComObject()). I'm not sure if that is related or not. I do connect to lots of different servers during the life of the process.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我有同一种应用程序，它在所有不同类型的设备上执行多个 WMI 查询，并且我遇到了相同的行为。使用 wbemtest 有时会更快，但不一定。我还发现同一台机器上的一些查询的行为与同一台机器上的其他查询不同，仅仅是因为不同的类是查询。
有一个属于 EnumerationOptions 类的 ReturnImmediately 属性，如果您批量获取结果而不是通过网络枚举它们，它可能会帮助您更快地获得结果。
您可以尝试一下，看看是否有帮助。我知道这不是您想听到的，但我个人的观点是您无能为力。您需要编写代码来解决该问题。真正的答案隐藏在 DCOM、WMI 协议和 WMI 存储库的深处。
I have the same kind of application that does multiple WMI queries on all different kinds of devices and I experience the same behavior. Using wbemtest is sometimes faster but not necessarily. I also find some queries on the same machine behave differently then other queries on the same machine simply because a different class is queries.
There is a ReturnImmediately property belonging to the EnumerationOptions class which might help you get the results faster if you get them in one batch instead of enumerating them over the network.
You can try that and see if it helps. I know this is not what you want to hear but my personal opinion is that there is not much you can do. You need to write code to work arround the issue. The real answer lies somewhere deep burried in the bowls of DCOM, the WMI protocol and the WMI repository.
您可以尝试将 WITHIN 字段设置为看看它是否强制查询更快发生。您可以发布您正在使用的查询吗？这可能有助于调试任何进一步的问题
You could try and set the WITHIN field to see if it forces the query to happen sooner. Could you post the query you are using? That might help debug any further issues
该问题是否特定于某个盒子？我曾经在远程处理场景中遇到过同样的问题。我通过在进行远程处理调用的机器上重建 TCP/IP 堆栈来修复此问题。
Is the problem specific to one box? I once had this same problem with a remoting scenario. I fixed it by rebuilding the TCP/IP stack on the box making the remoting call.
查看 WBEM_FLAG_RETURN_IMMEDIATE &您的语言的 WBEM_FLAG_FORWARD_ONLY 标志。当使用 Scriptomatic（来自 MS 的用于进行 WMI 调用的小型 VBScript GUI）时，此选项会自动添加为选项的一部分。 48 表示 WBEM_FLAG_RETURN_IMMEDIATE | WBEM_FLAG_FORWARD_ONLY。 VBScript 示例：
https://msdn.microsoft.com /en-us/library/aa390880(v=vs.85).aspx
Look into the WBEM_FLAG_RETURN_IMMEDIATE & WBEM_FLAG_FORWARD_ONLY flags for your language. When using Scriptomatic (great little VBScript GUI from MS for making WMI calls) this option is automatically added as part of the options. The 48 means WBEM_FLAG_RETURN_IMMEDIATE | WBEM_FLAG_FORWARD_ONLY. VBScript example:
https://msdn.microsoft.com/en-us/library/aa390880(v=vs.85).aspx