CPU Resources 不受 Solaris Resource Manager 控制

Solaris Resource Manager 只对 SHR 调度类中的进程的 CPU 使用加以控制。如果其它调度类，特别是 real-time (RT) 和 system (SYS)，以较高优先权提出过多要求的话，则 SHR 只能对剩余的 CPU资源进行调度。

RT 类的使用与 Solaris Resource Manager 软件对系统的控制能力相冲突。实时进程获得对系统的完全访问，特别是为了能够提供实时的响应（通常是几万分之一秒）。依照定义，SHR 类中运行的进程所拥有的优先权比任何实时运行的进程都要低，而 Solaris Resource Manager 并不控制 RT 进程。实时进程很容易就用尽全部的可用内存，使得没有为 Solaris Resource Manager 留下任何资源用于分配给其余的进程。

一个值得注意的完全在 SYS 类中运行的系统服务就是 NFS 服务器。 Solaris Resource Manager 无法控制 NFS 守护程序，因为它们是在 SYS 中运行的。在提供广泛的 NFS 服务的系统上， Solaris Resource Manager 产品的分配处理器资源的能力可能会遭到削弱。

在进程（在系统调用内）执行核心代码时，通常的时间片抢先规则并不适用。大多数系统调用只是进行了适中数量的工作就到达了一个抢先点。但是，如果系统承担的是更加剧烈的系统调用的高负载，则有可能导致整体响应下降，并且是在调度类的控制范围之外。

如果系统缺乏可用的实在内存，则随着页面故障率以及进程交换的增加，所导致的 I/O 瓶颈使得核心的 CPU 消耗增加。等候 I/O 时间太长，可能指示着 CPU 容量损失。而这又是在调度类的控制范围之外。

SHR 调度类是一个分时（TS）调度器。其所使用的全局优先权变程与 TS和 IA 调度器相同，除非是为了过渡而将所有的进程移入或者移出 SHR类，否则将 SHR 与 TS 和 TA 混在一起使用是不合适的。SHR 和 TS 类混合进行系统操作，将使两类的调度性能均遭到削弱。出于这个原因， Solaris Resource Manager 防止非根进程将其自身或者其它进程移到 TS 或者 IA 类。RT 类使用一个替代性的优先权变程，可以与 SHR 类一同使用，就象与 TS 和 TA 类一同使用那样。

如果根所运行的进程为了调整进程优先权，含有直接使用 priocntl(2) 系统调用而非使用 setpriority(3C) 库例行程序的代码，则这些代码可以将目标进程移入另一调度类（典型情况为 TS）。setpriority(3C) 库例行程序代码说明了一个事实，即priocntl(2)与 SHR 的接口与到 TS 的接口是二进制兼容的，从而避免了故障。-ps(1)的 c 选项或者 -priocntl(1)的 d 选项可以用于显示进程的调度类。

根优先权进程明确地使用 priocntl(2)来管理进程的调度类成员，因而也存在同样的困难。