计时数据是基于统计收集的,因此易于出现任何统计抽样方法的所有误差。对于时间非常短的运行(仅记录少量分析数据包),调用栈可能不能表示程序中使用大多数资源的各部分。因此应以足够长的时间或足够多的次数运行程序,以累积感兴趣的函数或源代码行的数百个分析数据包。
除了统计抽样误差外,收集和归属数据的方式以及程序在系统中前进方式也会引起特定的误差。以下是计时度量可能出现不准确或失真的一些情况:
创建 Solaris LWP 或 Linux 线程时,记录第一个分析数据包之前所用的时间少于分析间隔,但是整个分析间隔取决于第一个分析数据包中记录的微态。如果创建了许多 LWP 或线程,则误差可能是分析间隔的许多倍。
销毁 Solaris LWP 或 Linux 线程时,在记录最后一个分析数据包后会消耗一些时间。如果销毁许多 LWP 或线程,则误差可能是分析间隔的许多倍。
在分析间隔期间可能发生 LWP 或线程的重新调度。因此,记录的 LWP 状态可能不能表示消耗大部分分析间隔的微态。如果要运行的 Solaris LWP 或 Linux 线程多于要运行它们的处理器,则误差很可能更大。
程序可以与系统时钟相关联的方式运行。在这种情况下,如果 Solaris LWP 或 Linux 线程处于可能表示所用的一小部分时间的状态,而为特定程序部分记录的调用栈被过度表示,则分析间隔始终会过期。在多处理器系统上,分析信号可以引入相关性:记录微态时,在运行程序的 LWP 时由分析信号中断的处理器很可能处于陷阱 CPU 微态。
分析间隔过期时,内核记录微态值。如果系统负载过重,则该值可能无法表示进程的真实状态。在 Solaris OS 上,此情况很可能会导致对陷阱 CPU 或等待 CPU 微态的过多记帐。
系统时钟与外部源同步时,在分析数据包中记录的时间戳不反映分析间隔,但包括对时钟进行的任何调整。时钟调整可能使分析数据包看起来已丢失。涉及的时间段通常为几秒,并且调整是以增量方式进行的。
除了刚刚介绍的不准确外,计时度量还会因收集数据的过程而失真。记录分析数据包所用的时间从不出现在程序的度量中,因为记录是由分析信号启动的。(这是相关性的另一个实例。)记录过程中所用的用户 CPU 时间在所记录的任何微态之间分配。结果是对用户 CPU 时间度量过少记帐,而对其他度量过多记帐。记录数据所用的时间量通常不到缺省分析间隔的 CPU 时间的百分之几。