我正在使用三种方法来获取windows机器的CPU使用率：
psutil，间隔为 1 秒：
cpu_usage=psutil.cpu_percent(interval=1)
psutil，间隔为 10 秒：
cpu_usage=psutil.cpu_percent(interval=10)
WMI 包：
c = wmi.WMI()
query = "SELECT * FROM Win32_PerfFormattedData_PerfOS_Processor where name='_Total'
cpu_usage=c.query(query)[0].PercentUserTime
"`
测量值之间存在大约 30% 的差异； 我想知道每种方式的优缺点，哪种方式最准确。
【问题讨论】：
标签： python-3.x windows wmi psutil
了解 CPU 测量可变性的基础是了解 Windows 时钟节拍（构成测量的基础）和逻辑 CPU（在任何给定节拍中被测量为活动或空闲），以及您描述的方法的方式执行计算。
默认的 Windows 时钟频率为每秒 64 个滴答声，或每滴答声 15.625 毫秒。如果您查看 WMI 表 Win32_PerfRawData_PerfOS_Processor 中的递增滴答计数器（您上面引用的表在其计算中提取的原始数据），您会看到它们以 156250（100 纳秒滴答）的倍数递增。大量的纳秒给人一种错误的精确感，而实际上，每个处理器在每个测量间隔的开始和结束时都可以关闭一个刻度，最多 1/64 秒。
因此，您认为一秒所用的时间可能短至 62/64 秒或长至 66/64 秒，误差为 +/- 3.125%。没什么大不了的，但人们可能更喜欢 10 秒的间隔，范围为 +/- 0.3125%。
然而，这种缺乏精确性对于分子来说是一个更大的问题，因为您没有完整的秒数来处理。滴答在用户、系统和空闲每个逻辑处理器之间分开。例如，考虑一个具有超线程的四核系统，使用 25% 的 CPU、12.5% 的拆分系统、12.5% 的用户和 75% 的空闲。您有八个逻辑处理器。在每个处理器处于活动状态的 1/4 秒内，仅经过 16 个时钟节拍，系统模式下有 8 个节拍，用户模式下有 8 个节拍。但是，如果您选择了错误的开始和结束时间，您可能会低于或超过 2 个时钟节拍，8 个逻辑处理器中的每一个的范围为 6 到 10 个节拍。因此，如果您将整个系统的刻度加起来，您会得到 48 到 80 个刻度，而预期为 64，潜在误差高达 +/- 25%。相同情况下的两次独立测量可能会相差高达 50%。想要为整体 CPU 使用添加“用户+系统”吗？连续测量的差异高达 100%。当然，这些是最坏的极端情况，实际误差会更小，如果你在很长一段时间后对所有误差进行平均，它们会净为零。
现在，关于您在问题中的方法：
1 和 2：psutil.cpu_percent 在后台调用 GetSystemTimes。与 WMI 方法相比，这具有一个优势，因为您不会在对结果求和时遇到额外的错误。但是，请意识到您正在获得这些值的“自计算机启动以来的累计总时间”。使用率在 10% 到 30% 之间波动的系统每次都会为您提供大约 20% 的计算，几乎没有变化。为了测量较短时间范围内的 CPU 使用率，您需要保存上一次调用的结果，然后测量经过时间的差异。 （您还应该将经过的刻度相加以用作经过的时间，以避免进一步的不准确性。）在这种情况下，较长的计算间隔将减少错误，尽管您当然可以进行滚动计算（例如，每 1 次轮询秒，但使用 10 秒的历史使用值）。
3：WMI _Total 实例只是汇总各个逻辑处理器值，因此与 1 和 2 中基于系统的方法相比，精度不足（处理器越多越差）。此外，“格式化”数据基于类似名称表中的“原始”数据，经过的时间基于您的采样间隔。这意味着第一个样本将为您提供类似于第一种方法中的自开始使用累积的结果，但后来的样本将为您提供未更改的数据（如果您的间隔太短）或自上次以来的“当前”使用情况样本。除了相对缺乏对使用“格式化”数据的计算的控制（您可以通过手动计算“原始”数据来克服）WMI 还具有查询性能计数器的 COM 开销的缺点（有时第一次非常慢查询），而psutil 方法是直接的本机系统调用，重复使用要快得多。
总而言之：对于总系统时间，您最好使用psutil 值，但根据您选择的轮询间隔内连续测量之间的差异进行自己的计算。较长的时间间隔可提供更准确的测量结果，但测量使用高峰的能力较差。
WMI 让您可以更深入地了解每个处理器的使用情况，但要以开销换取查询的方便性。如果您真的想要这种用法，您可能希望直接从系统性能计数器（这是 WMI 最终获得它们的地方）获取它。
【讨论】：