性能计数器的性能影响是什么答案

【问题标题】：What is the performance hit of Performance Counters性能计数器的性能影响是什么
【发布时间】：2010-09-22 09:10:41
【问题描述】：

在考虑将性能计数器用作我公司基于 .NET 的站点时，我想知道使用它们的开销有多大。

我想让我的网站不断更新它的计数器还是我最好只在我测量时才这样做？

【问题讨论】：

【解决方案1】：

设置性能计数器的开销通常不足以担心（设置共享内存区域和一些 .NET 对象，以及 CLR 开销，因为 CLR 实际上为您进行管理）。这里我指的是 PerformanceCounter 之类的类。

注册性能计数器的开销可能相当慢，但通常不是问题，因为它打算在设置时发生一次，因为您想更改机器范围的状态。你所做的任何复制都会使它相形见绌。这通常不是您想要在运行时执行的操作。这里我指的是 PerformanceCounterInstaller。

更新性能计数器的开销通常归结为在共享内存上执行互锁操作的成本。这比正常的内存访问要慢，但它是一个处理器原语（这就是它在整个内存子系统（包括缓存）中获取原子操作的方式）。一般来说，这个成本并不高，不用担心。它可能是正常内存操作的 10 倍，可能更糟，具体取决于更新以及线程和 CPU 之间的争用情况。但是考虑到这一点，对于具有原子更新的跨进程通信，实际上不可能比互锁操作做得更好，并且不持有任何锁。这里我指的是 PerformanceCounter.Increment 和类似的方法。

读取性能计数器的开销通常是从共享内存中读取。正如其他人所说，您希望在合理的时间段内进行采样（就像任何其他采样一样），但只需考虑 PerfMon 并尝试将采样保持在人类规模（考虑秒而不是毫秒）并且您可能不会有任何问题。

最后，对体验的吸引力：性能计数器非常轻量级，以至于它们在 Windows 中无处不在，从内核到驱动程序再到用户应用程序。 Microsoft 在内部依赖它们。

建议：性能计数器的真正问题是理解的学习曲线（适中）和衡量正确事物的学习曲线（看起来很容易，但您经常会弄错）。

【讨论】：

【解决方案2】：

更新对性能的影响可以忽略不计。 Microsoft 的意图是您始终写入性能计数器。正是对那些性能计数器的监视（或捕获）会导致性能下降。所以，只有当你使用 perfmon 之类的东西来捕获数据时。

实际上，性能计数器对象仅具有“在测量时执行”的效果。

【讨论】：

谢谢。你能不能给我指出一些数字？我很好奇他们得到它有多好......
我从未见过它演示过，但我没有理由怀疑它。在应用程序中很容易证明。
嗨，德普林顿。 “是监控……会导致性能下降”是指在更新/发布计数器的过程中或在监控它们的过程中会看到性能下降？
我对指导的解释是前者。

【解决方案3】：

我已经对这些进行了很多测试。

在一台旧的 compaq 1Ghz 1 处理器机器上，我能够创建大约 10,000 个计数器并远程监控它们大约 20% 的 CPU 使用率。这些不是自定义计数器，只是检查 CPU 或其他。

基本上，您可以监控任何体面的较新机器上的所有计数器，而影响很小。

对象的实例化可能需要很长时间，从几秒到几分钟。我建议你为你收集的所有计数器多线程，否则你的应用程序将永远坐在那里创建这些对象。不确定 MS 在创建需要这么长时间后会做什么，但您可以同时为 1000 个计数器和 1000 个线程执行此操作，同时您可以为 1 个计数器和 1 个线程执行此操作。

【讨论】：

您是否测试过流程级别的指标？我发现它产生的开销比我想要的要多。我为大约 30 个不同的 pid 添加了 4 个计数器，并且看到监控应用程序占用了大约 20% 的 cpu。
没关系，这是愚蠢的杀毒软件，一切都很好。切换到异步方法来创建计数器是个好主意

【解决方案4】：

性能计数器只是指向共享内存（也称为内存映射文件）中 4/8 字节的指针，因此它们的成本与访问 int/long 变量的成本非常相似。

【讨论】：

【解决方案5】：

我同意 Famoushamsandwich 的观点，但要补充一点，只要您的采样率合理（5 秒或更多）并且您监控一组合理的计数器，那么测量的影响也可以忽略不计（在大多数情况下）。

【讨论】：

【解决方案6】：

我发现，对于大多数应用程序来说，它并没有那么慢。我不会把它放在一个紧密的循环中，或者每秒调用数千次的东西。

其次，我发现以编程方式创建性能计数器非常慢，因此请确保您事先创建它们，而不是在代码中。

【讨论】：