第 6 章 SHR 调度程序

Solaris Resource Manager SHR 调度程序可用于控制 CPU 资源的分配。份额的概念可使管理员轻松地控制用户、组、和应用程序对 CPU 资源的相对权利。份额的概念类似于在公司中股份的份额；重要的并不是您拥有多少份额，而是与其他股东相比您拥有多少份额。

技术描述

每个 lnode 都有四个与 Solaris Resource Manager CPU 调度程序相关的属性：cpu.shares、cpu.myshares、cpu.usage 和 cpu.accrue。liminfo(1SRM) 的输出可显示这些属性及其它有用的数值。

Solaris Resource Manager 调度是采用 SHR 调度类实施的。这包括对 nice(1)、priocntl(1)、renice(1) 和 dispadmin(1M) 命令的支持。在系统调用级别上，SHR 就相当于 TS 调度类。

份额

用户的 cpu.shares 属性可用于根据用户的 parent 活动的同级分配 CPU 权利。只有当一个用户具有活动的 child 用户时，该用户的 cpu.myshares 属性才有意义；该属性用于确定针对用户的 CPU 权利的分配。

例如，如果用户 A 和 B 是父节点 P 的唯一的两个子用户，则 A、B 和 P 每个均拥有组 P 内的一个份额（即，A 和 B 的 cpu.shares 设置为 1，而 P 的 cpu.myshares 设置为 1），因而三方各自均拥有合组的权利合计之三分之一的 CPU 权利。

所以，某个用户的实际 CPU 权利取决于父节点的相对权利。这反过来又取决于该父节点的 cpu.shares 相对于该父节点的 peers 及祖父节点的 cpu.myshares 的相对数值，并依此类推沿调度树向上进行比较。

鉴于系统管理的原因，附加到 root lnode 上的进程不受份额属性的影响。附加到 root lnode 上的任何进程均被给予它请求的几乎所有 CPU 资源。

任何大量耗用 CPU 的进程均不得附加到 root lnode 上，这一点非常重要，因为这会严重影响其它进程的执行。为避免这种情况，应该采取以下预防措施：

• 中央管理员帐户应该有自己的 UID，并与超级用户帐户不同。在登录并进行非管理任务时，应使用这个帐户。如果进行管理功能需要超级用户的 UID，则中央管理员应该使用 su(1) 命令更改 UID，同时仍使该帐户附加在自己的 lnode 上。

• srmuser(1SRM) 命令可被用于 init.d(4) 脚本中，并将任何守护程序附加到一个非 root lnode 上。在缺省状态下，在启动脚本中启动的任何进程均具有一个有效的 UID root，这些进程均被附加到该 root lnode 上。用户命令可使守护程序保持 root 的一个有效 UID，并附加到它们自己的 lnode 上。这样就能在任何守护程序大量耗用 CPU 时避免这些问题。

并非调度树中的所有组长都需要代表运行进程的实际用户，在这些情况下，不必把 CPU 的一个份额分配给它们。这样的 lnode 可通过将其 cpu.myshares 属性设置为零而表示。在这样的一个组长中的 cpu.accrue 属性仍包括对其组的所有成员进行的更改。

已分配份额

cpu.shares 和 cpu.myshares 属性用于确定每个活动 lnode 的当前 CPU 的已分配份额，形式是一个百分比。非活动用户的已分配份额对已分配份额没有任何区别。如果只有一个用户在活动，则该用户将拥有百分之 100 的可用 CPU 资源。如果只有同一组内份额相等的两个用户在活动，则每个用户将分得百分之 50 的份额。有关已分配份额的计算方法的详情，请参阅 已分配份额的计算。

利用率和衰变

每当一个附加到 lnode 上的一个进程因使用 CPU 而被收费，cpu.usage 属性就会增加。利用率属性值以利用率衰变通用 Solaris Resource Manager 参数所确定的速率呈指数衰变。利用率衰变速率（以秒为单位用半衰期表示）由 srmadm(1MSRM) 命令设置。

尽管所有的进程都拥有一个 lnode，无论其当前的调度类如何，但从来不对 SHR 调度类之外的进程进行收费。

应计利用率

accrued 利用率属性以与利用率属性相同的数量增加，但并不衰变。所以，它就表示自属性最后一次预设后已经附加到该 lnode 及其成员上的所有进程的总累计利用率。

有效份额

lnode 的已分配份额及其 cpu.usage 属性可确定其当前的有效份额。Solaris Resource Manager 调度程序可调节附加到一个 lnode 上的所有进程的优先权，这样它们工作的速率就与该 lnode 的有效份额成正比，而与附加到其上的可运行进程的数目成反比。

每一进程份额优先权（sharepri）

每个附加到某一 lnode 的进程，均拥有内部的针对 Solaris Resource Manager 的数据，由操作系统内核为其进行维护。对于调度来讲，这些值中最为重要的是 sharepri 值。在任何时候，sharepri 值最低的进程，将最有权得到调度，运行于某一 CPU。

份额分配示样

调度树结构

以下要点是关于调度树的结构的，这是要求中央管理员特别考虑的一个方面：

• 调度树就是被 Solaris Resource Manager 用来实施资源的分层结构和特权控制的结构。如果某个次级管理员获得了对该次级管理员一般不能访问的调度树的一个子树的控制，则该次级管理员无需中央管理员的许可就能获得对附加资源利用率和特权的访问权。发生这种情况的一种方式就是某个管理员删除了一个 lnode，但留下一个被孤立的子树。

• 中央管理员可使用 limreport(1SRM) 命令并通过采用内置孤立标识符辨别调度树的孤立部分。发现的任何孤立都必须立即重新附加。

• 当创建了一个新的 lnode 时，它大多是填充为零，这样就使多数标志具有 inherit 的缺省值。这对于多数标志来说都是期望的效果，因为它们被用于表示设备特权。有两种标志是在创建 lnode 是公开清空的，即 - uselimadm 和 admin 标志。这样就能防止新的用户自动获得任何管理特权。

树的描述

下面所示的树定义了包括若干组长和若干一般用户的结构。该树的顶部就是 root 用户。组长 lnode 采用两个整数表示，分别表示其 cpu.shares 和 cpu.myshares 属性的值。leaf lnode 采用一个整数表示，只表示其 cpu.shares 属性的值。

图形 6-1 调度树结构

已分配份额的计算

利用前面的示意图作为例子，节点 A、C 和 N 目前有附加在其上的进程。在最顶层，CPU 只需在 A 和 M 之间共享，因为没有针对 W 或调度组 W 的任何成员的进程。A 和 M 之间份额的比例为 3:1，所以最顶层的已分配份额对于组 A 为百分之 75，而对于组 M 则为百分之 25。

分配给 A 组的百分之 75 又会由其活动用户（A 和 C）分享，比率为其在 A 组中的份额（即 1:2）。注意，确定 A 的相对于其子用户的份额时使用的是 myshares 属性。A 因而获得组所分配的份额的三分之一，而 C 获得其余的三分之二。为 M 组分配的份额全部归于 lnode N，因为它是唯一带有进程的 lnode。

可用 CPU 的已分配份额的整体分配因此为：A 是0.25，C 是 0.5，而 N 是 0.25。

请进一步设想 A、C 和 N 进程都不断地要求得到 CPU，而系统最多只有两个 CPU。这样，Solaris Resource Manager 就对三方进行调度，以使单个的进程获得整个可用 CPU 的上述的百分比：

• 对于两个 A 进程：每个为百分之 12.5

• 对于 C 进程：百分之 50

• 对于三个 N 进程：每个为百分之 8.3

单个进程的进度速率得到控制，以满足每个 lnode 的目标。在拥有两个以上 CPU 和唯独这六个可运行进程的系统上，C 进程将无法消耗其百分之 50 的权利，剩余权利由 A 和 N 按比例分享。

Solaris Resource Manager 与 Solaris nice 程序的关系

Solaris 中的 nice 程序使得用户可以降低某一进程的优先权，从而正常的进程不会被不紧急的进程拖后腿。借助 Solaris Resource Manager，激励用户使用该程序的地方在于，在较低优先权条件下使用 CPU 时间，其收费速率降低。

Solaris Resource Manager 通过允许中央管理员偏移针对 sharepri 应用了 nice 的进程的衰变速率而实施这一效果。在 srmadm(1MSRM) 命令中的 pridecay 通用 Solaris Resource Manager 参数可用于针对具有正常和最大 nice 值的进程的优先权设置衰变速率。所有相交 nice 值的速率均在彼此之间采用内插法计算，并类似地外插到最小 nice 值。例如，对于正常进程的优先权（如 sharepri）可以 2 秒的半衰期衰变，而具有最大 nice 值的进程的优先权则可以 60 秒的半衰期衰变。

这样的效果是，使用 nice 减少其优先权的进程获得比同一 lnode 上的其它进程更少的 CPU 份额。在 Solaris Resource Manager 中， nice 对于在不同 lnode 上的进程的执行速率没有影响，除非可运行进程的队列超过 CPU 的数目。

Solaris Resource Manager 专门采用一个最大 nice 值（例如，用 nice -19 命令启动的进程）处理进程。只有当其它进程不请求 CPU 资源时，这些进程才会被授予 CPU 资源，否则它们就会空闲。

有关 nice 的详情，请参阅 nice(1) 和 nice(2SRM)。有关 Solaris Resource Manager 与其它资源控制功能的关系的信息，请参阅Solaris Resource Manager 与类似产品的差别。

动态重新配置

SunEnterprise 服务器的动态重新配置 (DR) 特性使得用户可以动态添加和删除系统插板，这些插板包含硬件资源，诸如处理器、内存以及 I/O 设备。出于调度目的， Solaris Resource Manager 保持对可用处理器资源的跟踪，并适当处理所发生的变化，公平地将目前可用的处理器资源重新分配给合格用户和进程。

鉴于 Solaris Resource Manager 控制的只是进程的虚拟内存的大小，而不是进程和用户所使用的实在内存，针对内存进行的某一 DR 操作的作用，对 Solaris Resource Manager 的进程限制核对并不构成任何影响。

srmidle Lnode

空闲 lnode (srmidle) 是被中央管理员分配而对内核的所有空闲 CPU 成本进行收费的 lnode。在安装时，用 41 的 UID 创建了 srmidle。srmidle lnode 应具有零份额，以确保附加在其上的进程只有当没有其它进程活动时才会运行。 srmidle lnode 是使用 srmadm 命令分配的。

在启动时，缺省空闲 lnode 就是 root lnode。在向多用户模式转变时，init.d 脚本将把该空闲 lnode 设置为帐户 srmidle 的 lnode，如果存在这样一个帐户的话。可通过指定一个不同的 lnode 来使用 /etc/init.d/init.srm 脚本而对这个行为进行定制。

如果该空闲 lnode 不是 root，则它就必须是 root 的一个直接子节点。

srmother Lnode

其它 lnode (srmother) 是被系统管理员分配的、作为在初始安装（其中 root 是缺省父节点 lnode）后后创建的新用户的缺省父节点的 lnode。系统在安装时自动创建的、不可更改的 srmother lnode 有缺省的 1 个份额，以确保附加在其上的 lnode 能访问 CPU。 srmother lnode 是用 43 的 UID 创建的。

srmother lnode 应该没有资源限制，有 1 个或更多 CPU 份额，没有特别的特权。

srmlost Lnode

在 Solaris Resource Manager 下，setuid(2SRM) 系统调用的一个副作用是将把调用进程附加到新的 lnode 上。如果附加的更改失败，则原因通常是该新的 lnode 并不存在，进程被附加到您在安装 Solaris Resource Manager 时所创建的 lost lnode (srmlost) 上。如果这个附加也失败，或没有指定 srmlost lnode，则 setuid 功能就不会受到影响，该进程会继续在其当前 lnode 上运行。

init.srm 脚本在向多用户模式转换的过程中设置 srmlost lnode。可以对该性能进行覆盖，方法是在 /etc/init.d/init.srm 文件中指定使用一个 lnode。为了避免安全出现缺口，srmlost lnode 应拥有一个 CPU 份额，且没有特别特权。如果您要更改这些值，请在进行更改时考虑该用户的要求。

srmlost lnode 是用 42 的 UID 创建的。