什么是系统抖动，系统抖动及解决方法详解

如果低优先级进程所分配的帧数低于计算机体系结构所需的最小数量，那么必须暂停该进程执行。然后，应调出它的所有剩余页面，以便释放所有分配的帧。这个规定引入了中级 CPU 调度的换进换出层。

事实上，需要研究一下没有“足够”帧的进程。如果进程没有需要支持活动使用页面的帧数，那么它会很快产生缺页错误。此时，必须置换某个页面。然而，由于它的所有页面都在使用中，所以必须立即置换需要再次使用的页面。因此，它会再次快速产生缺页错误，再一次置换必须立即返回的页面，如此快速进行。

这种高度的页面调度活动称为抖动。如果一个进程的调页时间多于它的执行时间，那么这个进程就在抖动。

系统抖动的原因

抖动导致严重的性能问题。考虑以下场景，这是基于早期调页系统的实际行为。

操作系统监视 CPU 利用率。如果 CPU 利用率太低，那么通过向系统引入新的进程来增加多道程度。采用全局置换算法会置换任何页面，而不管这些页面属于哪个进程。

现在假设进程在执行中进入一个新阶段，并且需要更多的帧。它开始出现缺页错误，并从其他进程那里获取帧。然而，这些进程也需要这些页面，因此它们也会出现缺页错误，并且从其他进程中获取帧。这些缺页错误进程必须使用调页设备以将页面换进和换出。当它们为调页设备排队时，就绪队列清空。随着进程等待调页设备，CPU 利用率会降低。

CPU 调度程序看到 CPU 利用率的降低，进而会增加多道程度。新进程试图从其他运行进程中获取帧来启动，从而导致更多的缺页错误和更长的调页设备队列。因此，CPU 利用率进一步下降，并且 CPU 调度程序试图再次增加多道程度。这样就出现了抖动，系统吞吐量陡降，缺页错误率显著增加。结果，有效内存访问时间增加，没有工作可以完成，因为进程总在忙于调页。

图 1 系统抖动

这种现象如图 1 所示，这里 CPU 利用率是按多道程度来绘制的。随着多道程度的增加，CPU 利用率也增加，虽然增加得更慢，直到达到最大值。如果多道程度还要进一步增加，那么系统抖动就开始了，并且 CPU 利用率急剧下降。此时，为了提高 CPU 利用率并停止抖动，必须降低多道程度。

通过局部置换算法或优先级置换算法，可以限制系统抖动。如果一个进程开始抖动，那么由于采用局部置换，它不能从另一个进程中获取帧，而且也不能导致后者抖动。然而，这个问题并没有完全解决。如果进程抖动，那么在大多数时间内会排队等待调页设备。由于调页设备的平均队列更长，缺页错误的平均等待时间也会增加。因此，即使对于不再抖动的进程，有效访问时间也会增加。

为了防止抖动，应为进程提供足够多的所需帧数。但是如何知道进程“需要”多少帧呢？有多种技术。工作集策略研究一个进程实际使用多少帧。这种方法定义了进程执行的局部性模型。

局部性模型指出，随着进程执行，它从一个局部移向另一个局部。局部性是最近使用页面的一个集合（图 2）。一个程序通常由多个不同的可能重叠的局部组成。

图 2 内存引用模式中的局部性

例如，当一个函数被调用时，它就定义了一个新的局部。在这个局部里，内存引用可针对函数调用的指令、它的局部变量以及全局变量的某个子集。当退出函数时，进程离开该局部，因为这个函数的局部变量和指令已不再处于活动使用状态。以后可能回到这个局部。

因此，可以看到局部是由程序结构和数据结构来定义的。局部性模型指出，所有程序都具有这种基本的内存引用结构。注意，局部性模型是目前为止缓存讨论的背后原理。如果对任何数据类型的访问是随机的而没有规律模式，那么缓存就没有用了。

假设为进程分配足够的帧以适应当前局部。该进程在其局部内会出现缺页错误，直到所有页面都在内存中；接着它不再会出现缺页错误，除非改变局部。如果没有能够分配到足够的帧来容纳当前局部，那么进程将会抖动，因为它不能在内存中保留正在使用的所有页面。

工作集模型

如上所述，工作集模型是基于局部性假设的。这个模型采用参数 △ 定义工作集窗口。它的思想是检查最近 △ 个页面引用。这最近 △ 个页面引用的页面集合称为工作集（如图 3 所示）。

图 3 工作集模型

如果一个页面处于活动使用状态，那么它处在工作集中。如果它不再使用，那么它在最后一次引用的 △ 时间单位后，会从工作集中删除。因此，工作集是程序局部的近似。

例如，给定如图 3 所示的内存引用序列，如果 △ 为 10 个内存引用，那么 t₁ 时的工作集为 {1，2,5，6，7}。到 t₂ 时，工作集已经改变为 {3，4}。

工作集的精度取决于△的选择。如果 △ 太小，那么它不能包含整个局部；如果 △ 太大，那么它可能包含多个局部。在极端情况下，如果 △ 为无穷大，那么工作集为进程执行所需的所有页面的集合。

因此，最重要的工作集属性是它的大小。如果系统内的每个工作集通过计算为 WSS，那么就得到：

D=ΣWSS_i

这里 D 为帧的总需求量。每个进程都使用其工作集内的页面。因此，进程 i 需要 WSS_i 帧。如果总需求大于可用帧的总数（D>m），则将发生抖动，因此有些进程得不到足够的帧数。

一旦选中了 △，工作集模型的使用就很简单。操作系统监视每个进程的工作集，并为它分配大于其工作集的帧数。如果还有足够的额外帧，那么可启动另一进程。如果工作集大小的总和增加，以致超过可用帧的总数，则操作系统会选择一个进程来挂起。该进程的页面被写出（交换），并且其帧可分配给其他进程。挂起的进程以后可以重启。

这种工作集策略可防止抖动，同时保持尽可能高的多道程度。因此，它优化了 CPU 利用率。工作集模型的困难是跟踪工作集。工作集窗口是一个移动窗口。对于每次内存引用，新的引用出现在一端，最旧的引用离开另一端。如果一个页面在工作集窗口内的任何位置被引用过，那么它就在工作集窗口内。

通过定期时钟中断和引用位，我们能够近似工作集模型。

例如，假设 △ 为 10 000 个引用，而且每 5000 个引用引起定时器中断。当得到一个定时器中断时，复制并清除所有页面的引用位。如果发生缺页错误，那么可以检查当前的引用位和位于内存的两个位，这两位可以确定在过去的 10 000〜15 000 个引用之间该页面是否被使用过。如果使用过，那么这些位中至少有一位会被打开。如果没有使用过，那么这些位会被关闭。至少有一位打开的页面会被视为在工作集中。

注意，这种安排并不完全准确，这是因为并不知道在 5000 个引用内的什么位置出现了引用。通过增加历史位的数量和中断的频率（例如，10 位和每 1000 个引用中断一次），可以降低这一不确定性。然而，服务这些更为频繁中断的成本也会相应更高。

缺页错误频率

虽然工作集模型是成功的而且工作集的知识能够用于预先调页，但是用于控制抖动似乎有点笨拙。采用缺页错误频率（PFF）的策略是一种更为直接的方法。

这里的问题是防止抖动。抖动具有高缺页错误率。因此，需要控制缺页错误率。当缺页错误率太高时，我们知道该进程需要更多的帧。相反，如果缺页错误率太低，则该进程可能具有太多的帧。

图 4 缺页错误频率

我们可以设置所需缺页错误率的上下限（图 4）。如果实际缺页错误率超过上限，则可为进程再分配一帧；如果实际缺页错误率低于下限，则可从进程中删除一帧。因此，可以直接测量和控制缺页错误率，以防止抖动。

与工作集策略一样，也可能不得不换出一个进程。如果缺页错误率增加并且没有空闲帧可用，那么必须选择某个进程并将其交换到后备存储。然后，再将释放的帧分配给具有高缺页错误率的进程。

实际上，抖动及其导致的交换对性能的负面影响很大。目前处理这一问题的最佳实践是，在可能的情况下提供足够物理内存以避免抖动和交换。从智能手机到大型机，提供足够内存，可以保持所有工作集都并发地处在内存中，并且提供最好的用户体验（除非在极端条件下）。