系统运行缓慢

进程连接到 root Lnode

鉴于系统管理的原因，连接到 root lnode 的进程可被分配其需要的几乎所有 CPU 资源。所以，如果在 root lnode 上连接与 CPU 相关的进程，它就会阻碍 CPU，并造成其它 lnode 上的进程减慢或停止。

可以采取下列预防措施来防止此类情况的发生：

• 管理员均应登录为管理员正常使用所创建的 lnode，而不能连接到 root lnode 上。如果需要连接到 root lnode，则应小心不得使用任何需要大量耗用 CPU 的应用程序，如编辑程序。要想不连接到 root lnode 就使用某个超级用户的 UID，则管理员可使用 su( 1) 命令。

• init.d 脚本不能被更改来使用 srmuser 程序以将所有 daemons 连接到其自身的 lnodes 上，因此它们不能（通过继承）连接到 root lnode 上。不过，不可总推荐此解决方案。这样可能成为一个负担，因为有大量的文件需要编辑，而且这种做法可能会限制以后将修补程序集成到一个系统中的能力。一个不需要手动执行此任务的解决办法正在研究之中。

  对于 Solaris Resource Manager 1.0 之后的发行版，在 /usr/srm/unsupport 目录中所提供的脚本 sbin_rc2 和 sbin_rc3 可用来部分解决这个问题。

作为 setuid-root 而运行的程序并不自动连接到 root lnode。通常，该进程保持连接到创建它的父节点的 lnode，而只有有效 UID 被更改。

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，LIA 混在一起使用是不合适的。SHR 和 TS 类混合进行系统操作，将使两类的调度性能均遭到削弱。出于这个原因，Solaris Resource Manager 防止非 root 进程将其自身或者其它进程移到 TS 或者 IA 类。RT 类使用一个替代性的优先权范围，可以与 SHR 类一同使用，就象与 TS 和 IA 类一同使用那样。

如果超级用户所运行的进程包含直接使用 priocntl(2) 系统调用的代码，而不是使用 setpriority(3C) 库例行程序来调节进程优先权，则目标进程就可能被移动到另一个调度类（一般是TS）之中。 setpriority 库例行程序代码说明一个事实，即至 SHR 的 priocntl 接口是与 TS 二进制兼容的，并因此避免了出现问题。ps1 的 -c 选项或 priocntl(1) 的 -d 选项可用于显示进程的调度类。

显式地使用 priocntl(2) 来管理进程的调度类成员资格的超级用户特权进程也存在同样的难点。