第 2 章 常规操作

本章描述操作和关键性概念方面的 Solaris Resource Manager 原则。提供有示例，用于加强描述和解释 Solaris Resource Manager 的某些常见使用方法。

Lnode 概述

Solaris Resource Manager 是围绕着一个称为 lnode （限制节点）的对Solaris 核心所进行的一项根本性补充而建立起来的。lnode 与 UNIX UID 相对应，可以代表单个用户、用户组、应用程序以及特别要求。lnode 是通过 UID 进行索引的，用于在用户、用户组和/或应用程序级别，对资源分配策略以及进程的应计利用率数据进行记录。

分层结构

Solaris Resource Manager 管理模型将 lnode 组织成为一个称作调度树的分层结构。调度树是通过 UID 加以组织的：每个 lnode 指向 lnode 在树中的父节点的 UID。调度树的每个子树称为一个调度组，位于某一调度组根部的用户就是该组的组头目，根用户就是整个调度树的组头目。可以委托一个组头目对组内的资源策略进行管理。lnode 是通过分析 UID 文件而首先创建出来的。lnode 管理命令（limadm(1MSRM)）会在 Solaris Resource Manager 安装之后创建补充 lnode，并将 lnode 指派给父节点。调度树数据存储于一个随时可以根据需要进行修改的平面文件数据库。

尽管 lnode 所使用的 UID 并不一定要与某一系统帐户相对应，但由于其在系统口令映射中有一个条目，所以强烈建议为每个 lnode 的 UID 创建一个系统帐户。对于非叶的 lnode（即在分层结构中下面有从属 lnode 的 lnode）来讲，与该 lnode 相关联的的帐户只是管理性的，没有人曾经进行过登录。但是，其同样也有可能是某一真实用户的 lnode；该用户确实进行登录并运行附加到该非叶 lnode 的进程。

注意， Solaris Resource Manager 调度组和组头目与 /etc/group 数据库中所定义的系统组无关。包括组头目在内的调度树的每个节点，均与一个具有唯一 UID 的真实的系统用户相对应。

分层结构限制

如果为某一 lnode 树的一个组头目（调度组）指派了一个分层结构限制，则其适用于该用户的利用率以及调度组的所有成员的利用率。这就允许对单个成员乃至整个组进行限制。资源分配给组头目，而组头目又可以将其分配给属于同一组的用户或者用户组。

进程

每个进程均附加到某一 lnode。init 进程总是附加到根 lnode。进程如果是由 fork(2) 系统调用创建的，就附加到与其父节点相同的 lnode 上。只要有足够的特权，就可以借助 Solaris Resource Manager 系统调用，将进程重新附加到任意的 lnode 上。特权是由根或者是由正确的管理权限得到启用的用户加以设置的。

资源控制

Solaris Resource Manager 提供有对下列系统资源的控制：CPU（处理器速率）利用率、虚拟内存、进程数目、登录数目以及终端连接时间。

Solaris Resource Manager 对每个用户的对每个资源的利用率进行跟踪。对于除 CPU 利用率之外的所有其它资源，均可以为用户指派硬性的资源利用率限制。如果用户允许利用率到达极限的话，硬性限制将会促使资源消耗企图失败。硬性限制是直接由核心或者负责管理相应资源的软件加以执行的。限制值为零时，指示着无限制。根 lnode 的所有限制属性的设置，均应保留为零。

Solaris Resource Manager 不断使过去的利用率发生衰变，从而只有最近的利用率才有意义。系统管理员设置半衰期参数，对衰变速率进行控制。长的半衰期支持平稳的利用率，是较长的成批作业的典型情况，而短的半衰期支持交互式用户。

一般来讲，所有的系统资源均可以划分为两类中的一个：固定（或者不可更新）资源和可更新资源。 Solaris Resource Manager 以不同方式管理这两类资源。

固定资源

固定或者不可更新资源是那些可用数量有限的资源，诸如虚拟内存、进程数目、登录数目以及连接时间。可以对固定资源进行消耗（分配）和撤回（取消分配），但在其拥有者取消其分配之前，其它实体均无法使用该资源。 Solaris Resource Manager 运用一种利用率和限制模型，对所使用的固定资源的数量加以控制。利用率被定义为当前正在使用的资源，而限制就是 Solaris Resource Manager 所允许的最大利用率程度。

可更新资源

可更新资源是那些可以持续供应的资源，诸如 CPU 时间。可更新资源只可以消耗，且一旦消耗，就无法收回。在任何一个时间点上，某一可更新资源只有有限的可用性，且如果当时没有得到利用，则在将来就不再可用。（可以用阳光作类比。某一特定瞬间，只有一定数量的阳光从太阳到达地面，但在未来几百万年的时间里将会有更多会到达地面。）出于这个原因，将可更新资源重新指派给其它的用户就可以确保避免浪费，而不必将其明确进行重新分配。 Solaris Resource Manager 采用一种利用率、限制和衰变模型，对某一用户对某一可更新资源的的消耗速率加以控制。利用率被定义为所使用的资源总额，对相对于其他同类用户的利用率速率加以设置。衰变是指不再对历史利用率进行计算的时间段。下一个资源量，例如时钟周期，将被分配给活动的 lnode，与其所分配的份额相比，其衰变利用率值总计最低。衰变利用率值所衡量的是一段时间以来的利用率总额减去半衰期衰变模型所确定的历史利用率的某些部分。

CPU 资源是借助 Solaris Resource Manager 的 SHR 调度器加以控制的。用户所分得的 CPU 时间，与其所拥有的份额数目成正比（类似于所持有的公司股份），而与其最近的利用率成反比。SHR 调度器的重要特性就是，在其对单个线程的调度进行管理的同时（从技术角度讲，在 Solaris 中，所调度的实体是一个轻量进程（LLW）），还在各用户之间分配 CPU 资源。

每个用户还拥有一套标志，这是一些类似于布尔的变量，用于启用或者禁用可选的系统特权，例如登录。可以针对每一用户单个对标志进行设置，也可以从父 lnode 继承标志。

某一用户的利用率、限制以及标志可以为任意用户所读取，但只可以由拥有管理权限的用户加以更改。

CPU 资源管理

对可更新 CPU 服务分配的控制，是借助公平共享调度器进行的。每个lnode 被指派若干的 CPU 份额，这类似于某个公司的股份。与每个 lnode相关联的进程分得与其未使用活动份额的总量成正比的 CPU 资源；这里的活动指的是该 lnode 附加有正在运行的进程。只有活动的 lnode 才考虑为其分配资源，因为只有它们正在运行某一进程并需要 CPU 时间。随着一个进程消耗 CPU 周期，其 lnode 的 CPU 利用率属性也在增加。调度器不断地调整所有进程的优先级，以便使各自级别上的所有活动 lnode 的CPU 利用率相对速率与其 CPU 份额相吻合。这样，就长期而言，用户就至少有望得到其应得的CPU服务，而无论其它的用户的性能如何。调度器是分层结构的，这样就确保组可以独立于各成员的性能而收到组的权利。 Solaris Resource Manager 是一个长期的调度器；它确保所有的用户以及应用程序在"调度器的期限"内收到公平的份额。这意味着，当一个轻的用户开始请求 CPU 时，该用户将相应地收到比重用户多的资源，直到其比较性利用率与其相对的"公平"份额分配取得一致。您超出权力使用得越多，您在将来所能获得的就越少。另外， Solaris Resource Manager 有一个衰变期，由系统管理员设置，忘却过去的利用率。衰变模型属于半衰期类型，即在半个周期内，资源的百分之50发生衰变。这就确保稳定、均匀的用户不会受到短期、进程密集型的用户的不良影响。半衰期对调度器的响应或者"期限"进行设置；默认值为120秒钟。较短的值倾向于在整个系统范围内提供更加均匀的响应，其代价就是在计算和维护全系统的资源分配方面有点不太精确。无论管理设置如何，即使是在极端的情况下，调度器均试图避免孤立（资源饥荒），并确保合理的性能。

Solaris Resource Manager 调度器相对于标准调度器的的主要优势，在于其调度的是用户或者应用程序，而不是单个的进程。与某一 lnode 相关联的每一个进程都要受到一定的限制。在一个用户运行单一活动进程的简单情况下，这与让每个进程受到相对应的 lnode 中所列出的限制的情形一样。当有多于一个的进程附加到 lnode 上时，例如当某个组的成员均各自运行多个进程时，所有的进程作为一个整体，均受到所列出的限制。这意味着，无论当前其所运行的进程的数目，用户或者应用程序无法以超出其权利所允许达到更高的速率消耗 CPU。将权利指派为若干份额的作法，简单而易于理解，且对一个用户的份额进行更改的效果也是可以预测的。

Solaris Resource Manager 从不浪费 CPU 的可用性。无论某个用户的分配所得有多低，如果没有竞争用户的话，该用户就总能得到可用 CPU 的全部。其后果之一就是用户可能会注意到性能没有以前那样流畅了。如果某个拥有很低的有效份额的用户正在没有竞争的情况下运行一个交互式的进程，则看起来运行得很快。但是，一旦其他某个拥有较高有效份额的用户要求得到一些 CPU 时间，则会优先于第一个用户而给予该用户，因而第一个用户会注意到其工作速度明显减慢。但是， Solaris Resource Manager 会采取某些措施，以确保合法用户没有因遭到孤立而完全无法工作。 Solaris Resource Manager 所调度的所有进程（带有最大 nice 值的进程除外），将由调度器经常性地进行 CPU 分配。另外还有逻辑，用于防止某个刚刚登录的新用户获得算术上"公平"但是比例过大的 CPU，从而避免现有用户受损。

虚拟内存（针对每个用户和每个进程的限制）

虚拟内存是借助一个固定资源模型而加以管理的。虚拟内存限制应用于所有附加到 lnode 的进程的内存大小的总和。另外，也有针对每个进程的虚拟内存限制，用于对进程的虚拟地址空间大小的总额加以限制，其中包括所有的代码、数据、堆栈、文件映射以及共享库。两种限制都是分层结构的。限制虚拟内存有助于避免虚拟内存饥荒。例如，对于因为消耗未经授权数量的虚拟内存而使内存流失和所有用户受损的应用程序， Solaris Resource Manager 将予以终止。此类进程只会使其自身挨饿，或者更糟的话，也使其资源组内的其它进程挨饿。

进程数目

用户可以同时运行的进程的数目是借助一种带有分层结构限制的固定资源模型加以控制的。

终端和登录连接时间

系统管理员和组头目可以设置终端登录特权、登录数目以及连接时间限制，这些是由 Solaris Resource Manager 按分层结构强制执行的。当一个用户接近某个连接时间限制时，就会向该用户的终端发送警告消息。而当达到限制时，会通知该用户，并在较短的一个宽限时间段过后强行将其注销。

用户管理

系统管理员可以为任意的 lnode 设置管理特权，其中包括有选择地向用户指派管理特权。拥有分层结构管理特权的用户称作分管理员。分管理员可以创建、删除和修改其作为组头目的子树内的用户的 lnode。

分管理员无法按常规更改其自身的限制或者标志，且无法通过更改其组内的标志或者利用率来绕过其自身的标志或者限制。

中央管理员（或者超级用户）可以任意变更用户的限制、利用率和标志，其中包括其自身。可以通过设置一个标志而将该特权授予普通用户。

利用率数据概述

Solaris Resource Manager 系统对管理员为进行全面的系统资源记帐而可能会用到的信息（当前主要的和应计资源利用率）加以维护。 Solaris Resource Manager 自身并不包括任何记帐程序，但其实用程序却提供有开发定制资源记帐系统的基础。

如要了解更多关于设置记帐步骤的信息，请参阅 第 8 章，利用率数据.

示例

本节中的示例用于示范用来控制系统资源和分配以及显示信息的各种 Solaris Resource Manager 功能。

服务器整合示例

第一个示例用于解释下面这些命令：

liminfo

将一个或者多个用户的口令属性和限制信息打印到某个终端窗口

limadm

改变一列用户的限制属性或者删除其限制数据库条目

srmuser

对操作模式以及系统范围的 Solaris Resource Manager 可调节的参数进行显示或者设置

srmstat

显示 lnode 活动信息

请考虑将两个各自均运行某个数据库应用程序的服务器整合到单个机器的情形。简单地在单个机器上运行上述两个应用程序可以使系统工作起来；如果 没有 Solaris Resource Manager ，Solaris操作系统就将资源平均分配给两个应用程序，且并不对应用程序进行 保护，以使其免遭互相竞争损害。但是，Solaris Resource Manager 提供有用于避免应用程序缺乏资源的机制。 Solaris Resource Manager 启动每个数据库时均将其附加到指向该数据库的 lnode，即 db1 和 db2 ，从而取得上述效果。为此，必须创建三个新的管理性占位用户，例如 databases（数据库）、db1 以及 db2。这些被添加到 lnode 数据库；鉴于 lnode 对应于 UNIX UID，也还必须将其添加到 passwd 文件（如果系统是在运行某个名称服务，诸如 NIS 或者NIS+，则为口令映射）。假设是将 UID 添加到 passwd 文件或者口令映射，就使用下面的命令将占位用户 db1 和 db2 指派给 databases lnode 组：

%  limadm set sgroup=0 databases
%  limadm set sgroup=databases db1 db2

其中假设 /usr/srm/bin 是在用户的路径中。

图形 2-1 服务器整合

因为没有其它的已定义组，所以当前 databases 组完全使用机器。两个与数据库相关联的 lnode 正在运行，且在该数据库实例的启动正文中使用 srmuser 命令，就可以将运行数据库应用程序的进程附加到适当的lnode，例如：

% srmuser db1 /usr/bin/database1/init.db1
% srmuser db2 /usr/bin/database2/init.db2

当其中任何一个数据库，db1 或者 db2 被启动时，请使用 srmuser 命令，以确保该数据库被附加到正确的 lnode，且对其进行正确的收费（srmuser 并不影响进程进行此类操作的拥有权）。如要运行上述命令，用户必须拥有运行 init.db1 所需的许可，以及将进程附加到 lnode db1 的管理许可。随着用户登录并使用数据库，数据库所进行的活动就被计入 lnode db1 和db2。

借助每个 lnode 分配一个份额的默认方式，数据库组的利用率会最终平均开来，从而确保数据库 db1 和 db2 收到平等的机器资源分配。特别是，有一个未决份额-用于 databases 组-，且 databases 拥有它。lnode db1 和db2 中的每一个也会得到一个份额的默认分配。在数据库组内部，有两个未决份额，因而 db1 和 db2 获得 databases 的资源的平等分配（在上述简单示例中，没有竞争分配，因而 数据库可以访问整个系统）。

如果结果是 Database1 上的活动需要机器的 CPU 容量的百分之60，而 Database2 需要上述容量的百分之20，则管理员可以通过增加分配给 db1的 cpu.shares 的数目，指定系统至少提供上述数量（假设应用程序要求得到该数量）:

%  limadm set cpu.shares=3 db1

目前在 databases 组中有四个未决份额；db1 有三个，而 db2 有一个。一旦执行上述命令，则该变更立即生效。还将有一个决算期，lnode db1(Database1)才会真正收到比其应得的百分之60多的机器资源，因为 Solaris Resource Manager 将随着时间的推移对利用率进行平均，但是，该时间不会太长，这取决于衰变全局参数。

如要在任意点对该活动进行监测，请在不同的窗口中使用 liminfo 和 srmstat 命令：

%  liminfo -c db1
       # limit information shows all the data and 
       # settings for the lnode db1.

参阅 "典型的应用程序服务器"。

另外，srmstat 提供了一个定期更新的显示：

%  srmstat -ac      # srmstat shows the server activity and the 
                    # flag -ac sets a screen default update period 
                    # of 4 seconds to display the results.

您现在拥有一个运行有两个数据库应用程序的机器，一个程序收到百分之75的资源，另一程序收到百分之25。请记住，超级用户（根）是顶级的组头目用户。因而作为根而运行的进程如果要求的话，就可以访问整个系统。应当相应地为正在运行的备份程序、守护程序以及其它的正文创建附加的 lnode，以使根进程无法接管整个机器，而如果是以传统方式运行的话，则根进程就有可能接管整个机器。

添加计算批处理应用程序用户

本示例介绍的是下列命令：

srmkill

用于中止附加到某一 lnode 的所有活动进程

财务部门拥有数据库系统，但来自工程部门的一个用户（Joe）必须运行一个计算任务，想在系统通常空闲的非高峰时间使用财务部门的机器。财务部门断定 Joe 的任务没有数据库重要，同意只在其不干扰系统的主要工作的条件下才可以运行他的工作。如要强制执行该策略，需将一个新的组（batch）添加到 lnode database，并将 Joe 添加到服务器 lnode 分层结构中的新的 batch 组。

图形 2-2 添加计算批处理应用程序

该命令序列改变份额分配，以使 databases 组拥有20个份额，而使 batch组只拥有一个。这就指定 batch 组的成员（只有Joe），在 databases 组活动时最多只能使用机器的1/21。而 databases 组收到20/21或者说百分之95.2，多于以前确定为足够用来处理数据库工作的60% + 20% = 80%。如果 databases 没有要求得到其全部分配，则 Joe 所收到的将多于分配给他的百分之4.8。如果 databases 完全不活动，则 Joe 的分配可能会达到百分之100。但分配给 databases 的未决份额的数目从1增加到20时，就没有必要对 db1 和 db2 的份额分配进行任何更改。在 databases 组内部，仍然有四个未决份额，其分配比率为3:1。调度树的不同层次之间是完全独立的；关键是同级组之间的份额比率。

即使有了这些把握，财务部门仍旧想确保 Joe 无法在白天高峰时间登录。这在 batch 组上放置一些控制就可以办到。鉴于控制对一天内的时间敏感，实现起来可以是在一天开始和结束时运行一个正文，从而改变 batch组所允许的登录数目。例如，可以借助 crontab 条目加以实现，诸如：

0 6 * * * /usr/srm/bin/limadm set logins=0 batch
0 18 * * */usr/srm/bin/limadm set logins=100 batch

在早晨6点钟，batch 的登录限制减少为0，而在18点钟（下午6点钟），限制上升为允许多达100个登录。

还可以实现一个更为严格的策略，方法是将另一行添加到 crontab 条目：

01 6 * * * /usr/srm/bin/srmkill joe

这使用的是 srmkill 命令，用于在早晨6点零1分时中止任何附加到 lnode Joe 的进程，如果该任务所需的唯一资源正是 Solaris Resource Manager 所控制的资源的话，就没有这个必要。如果有理由认为 Joe 的任务可能会独占其它资源从而对正常工作造成干扰的话，就可以使用上述操作。例如某个任务使某个关键性的数据库锁定或者独占某个 I/O 通道。

现在 Joe 只能在夜间登录运行其任务了。由于 Joe（以及整个 batch 组）所拥有的份额比其它应用程序少得多，他的应用程序运行时只能使用百分之5的机器。同理，nice(1)可以用来降低附加在该任务上的进程的优先级，从而使其运行时所拥有的优先级低于正在运行的其它拥有同等 Solaris Resource Manager 份额的任务。

现在，财务部门就确信其数据库应用程序可以对其系统进行足够的访问，且其工作不会互相干扰了。他们在提供 Joe 连夜批处理负载的同时，还确保他的工作不会干扰其关键任务的处理。

发动万维网前端进程

假设业已决定在 Database1 上放置一个万维网前端，但将该应用程序限制为只能10个用户同时登录。使用进程限制功能就能办到。

首先，创建一个名为 ws1 的新 lnode。您通过在 ws1lnode 下启动Webserver （万维网服务器）应用程序，就可以控制其可用的进程的数目，也就是活动 http 会话期间的数目。

图形 2-3 添加万维网前端进程

鉴于 Webserver 是 Database1 应用程序的一部分，您可以给予它一个 db1lnode 份额，并允许它与 Database1 争用资源。给 Webserver 分配百分之50 的计算机资源，而给 Database1 应用程序自身分配百分之40：

#  limadm set cpu.shares=6 ws1
#  limadm set sgroup=db1 ws1
#  limadm set cpu.myshares=4 db1
#  srmuser ws1  /etc/bin/Webserver1/init.webserver

最后一行启动 Webserver，并将应用程序装载到 ws1lnode。注意，为Database1 的 cpu.myshares 分配了4。这就为 db1 与其子进程 Webserver竞争份额设置了4:6的比率。

cpu.shares 显示分层结构中同级资源分配的比率，而 cpu.myshares 显示的是父节点正在积极运行应用程序时父:子节点的资源分配比率。 Solaris Resource Manager 根据所有活动 lnode 在其各自层次上的未决份额的比率来进行资源分配，其中"各自层次"包括所有组父节点和所有子节点的 my.shares。

如要控制 Webserver 可以运行的进程的数目，就为 ws1lnode 放置一个进程限制。示例使用的是20，因为一个 Webserver 查询通常产生2个进程，因而这实际上将活动 Webserver 查询的数目限制在10：

# limadm set process.limit=20 ws1

现在业已将又一应用程序作为某个活动 lnode 下的一个叶节点添加到了调度树。如要在活动的父节点和子节点之间分布 CPU 资源，就使用 cpu.myshares 来将某些部分的可用资源分配给父节点，将某些分配给子节点。采用了进程限制，以便对一个 lnode 上的活动会话期间的数目加以限制。

添加更多有特殊内存要求的用户

本示例实现的是 CPU 共享、进程限制和登录控制等资源控制机制，并涉及到用于打印 lnode 和显示活动 lnode 的显示工具。

srmadm

管理 Solaris Resource Manager

limreport

输出关于所选用户的信息

limdaemon

指示守护程序在到达任何限制时发送消息

另一用户 Sally，也为其应用程序要求在夜间使用机器。鉴于她的应用程序是 CPU 密集型的，为确保 Joe 的应用程序不受损害，需给 Sally 的虚拟内存利用率放置一个限制，既包括她的总利用率，也包括她的"每一进程"利用率。

%  limadm set memory.limit=50M sally
%  limadm set memory.plimit=25M sally

图形 2-4 添加更多的用户

如果 Sally 的应用程序试图超过她的总虚拟内存限制或者进程内存限制，limdaemon 命令将通过控制台通知 Sally 和系统管理员，业已超过了限制。

使用 limreport(1MSRM) 命令来生成一个报告，显示正在系统上的人及其到目前为止的利用率。limreport 的一个典型运用就是在任意时刻查看谁在使用机器及其在用户分层结构中的状态如何。

% limreport 'flag.real' - uid sgroup lname cpu.shares cpu.usage |sort +1n +0n

limreport 拥有多个参数。在本示例中，对 "flag.real" 进行了检查（只寻找"真"的 lnode/UID），然后又使用了破折号（-），指示输出格式应当使用默认的最佳的猜测，而列表"uid sgroup lname cpu.shares cpu.usage"指示 limreport 应当为"flag.real"设置为"真"的每个 lnode 输出这5个参数。输出在第二列上被导向一个 UNIX 主排序，而在第一列上被导向一个次排序，从而提供一个谁正在使用服务器的简单报告。

任何拥有正确路径和许可的人，均可以在任意时刻借助 srmadm show 命令来检查 Solaris Resource Manager 的状态。这将输出一个格式化报告，显示 Solaris Resource Manager 及其主要配置参数的当前操作状态。这可以用于检查 Solaris Resource Manager 正在活动且所有的控制参数正在活动。还可以用于显示全局参数的值，诸如衰变速率以及 Solaris Resource Manager 数据仓库的位置。

在不让限制活动以及不让 CPU 调度活动的情况下，是有可能运行 Solaris Resource Manager的，这一点对在启动时对 Solaris Resource Manager 进行调试和初始配置很有价值：

# srmadm set share=n:limits=n, -

跨部门共享机器

一个不同的开发组想要花钱为该机器升级（增加处理器和内存），以便可以在系统空闲时进行访问。两个组都可以从中受益。如要进行设置，需再建立一个新的组，名为 development，且是在与 databases 和 batch 相同的层次上。为 development 分配机器的百分之33，因为是他们为原来的系统添置了另外百分之50的 CPU 能力和内存：

图形 2-5 共享机器，步骤1

开发组拥有成百上千的用户。为了避免卷入对其资源的分散，需使用 Solaris Resource Manager 的管理标志功能，以便使开发系统管理员可以分配其资源。您依照多方联合商定的方案对操作和开发层次的限制加以设置，然后你们双方开始操作，对各自部分的机器进行控制。

如要为分层结构添加新的层次，请作为一个新的 lnode 添加 operations组，并将 batch 和 databases 的父组改为 operations：

% limadm set sgroup=operations batch databases

如要设置管理标志：

% limadm set flag.admin=set operations development

鉴于在正常的环境下，所有的服务器都需要运行守护程序和备份程序，因而应当在另外的高层 lnode 上进行上述添加。

不要使用根，因为根没有限制。

图形 2-6 共享机器，步骤2

正如在示例中所看到的那样，您可以使用 Solaris Resource Manager 来将多个不同类型的用户和应用程序整合在同一机器上。通过审慎使用 CPU 份额控制、虚拟内存限制、进程限制以及登录控制，您可以确保这些各式各样的应用程序只收到其需要且要求得到的资源。限制用于确保没有任何应用程序或者用户会对任何其他用户的或者用户组的应用程序构成不良影响。 Solaris Resource Manager 支持一些简单的汇报工具，用于向用户和系统管理员显示任意时刻以及一段时间以来所发生的确切情况。报告生成功能可以用来跨应用程序和组显示资源利用的细节，以便进行容量规划和记费。

典型的应用程序服务器

在上面一节示例的结尾处用 liminfo 得出的 db1 列表会显示本输出。键入：

# liminfo -c db1

输出：

图形 2-7 liminfo 列出

参考 liminfo(1SRM)，可以得到更多有关下面所描述的字段的信息。

来自 liminfo(1SRM)命令的输出的前两行涉及 lnode UID 及其在 lnode树中的位置等方面。

登录名称

来自于与所附加的 lnode 的 UID 相对应的口令映射的登录名称和初始 GID。每个 lnode 均与一个系统 UID 相关联。强烈建议为每个 lnode 创建一个系统帐户。在本实例中，为db1（Database1)数据库1使用了一个占位 UID。

注意， Solaris Resource Manager 下的默认 PAM 配置是，为登录时没有 lnode 的任何用户创建一个 lnode。默认情况是，由根或者由某个用户借助uselimadm 标志创建的 lnode，创建时是将用户 other 的 lnode 作为其父节点；如果不存在，就将根 lnode 作为父节点。由某个用户借助设置管理标志而创建的 lnode，创建时是将该用户作为其父节点。可以借助用于更改 lnode 属性的一般命令，limadm，对 lnode 的父节点进行更改。

Uid

附加到当前进程的 lnode 的 UID。通常与进程（已登录用户）的真实的 UID 相同，但在某些情况下（后面有描述），可能有所不同。

R、Euid 和 R、Egid

当前进程的真实和有效 UID 和 GID，这与标准系统 id(1M) 命令所提供的信息相同。这不是严格与 Solaris Resource Manager 有关，而只是为了方便才加以显示的。如果 liminfo(1SRM) 是在显示有关某个用户的信息，而不是默认的信息（即，是用登录名称或者 UID 作为变元提供的），则不显示这些字段。

Sgroup (uid) [sgroup]

lnode 树分层结构中父 lnode 的名称和 UID。如果是根 lnode，则为空。许多 Solaris Resource Manager 特性取决于某一 lnode 在树分层结构中所处的位置，因而这有助于用户跟踪连续的父 lnode，一直回到树的根。

在空白行之后，liminfo(1SRM) 的下面两行显示与 CPU 调度有关的字段。

Shares [cpu.shares]

这是分配给该用户的 CPU 权利份额的数目。这只与拥有同一父 lnode 的其他用户，以及父 lnode 自身的"Myshares" 具有直接的可比性。管理员通常可以将某一具体调度组中的所有用户的份额设置为同一值（给予这些用户平等的权利）。该值通常为大于1的某个数，从而留有余地，使管理员可以在适当的时候减少某些用户的份额。

Myshares [cpu.myshares]

只有该用户有正在活动（即，有附加进程）的子lnode时才使用该值（即，如果其它 lnode 拥有该用户的sgroup 值）。如果情况确实是这样，则该值给出的是附加到该 lnode 的相关的 CPU 值的份额，可以与附加到其子 lnode 的 CPU 值的份额进行对比。

份额

计算得出的当前用户有权使用的系统 CPU 资源的百分比。随着其他用户登录和注销（或者 lnode 变为活动或者不活动），该值也将发生变化，原因在于计算只会将活动的用户计算在内。该计算并不包含当前用户的最近利用率。

E-Share

这是该用户的有效份额（即，只要该用户要求且其他用户也在要求得到各自的份额，该用户就可以在短期内得到的系统 CPU 资源的实际百分比）。可以将此看作当前 Solaris Resource Manager 愿意分配给该 lnode 的 CPU 资源。该值会随着时间的推移，用户使用（或者不使用）CPU 资源，而发生变化。活动但空闲（即，所附加的进程休眠），因而利用率较低的 lnode 将拥有一个高效的份额值。相应地，对于所附加的进程正在积极使用 CPU 的用户来讲，其有效份额十分小。

Usage [cpu.usage]

用于确定调度优先权的累计系统资源利用率。其典型情况是指示最近的 CPU 利用率，但有可能还将其它参数考虑在内。可以借助 srmadm(1MSRM)命令查看参数混成情况。该值的每一增量随着时间的推移而发生指数衰变，从而最终 Solaris Resource Manager 将资源利用率"忘却"。用半衰期表示该衰变的速率则非常容易，可以借助 srmadm(1MSRM)命令进行查看。

Accrued usage [cpu.accrue]

这与"利用率"是相同的资源累计量度，但其从来不衰变。 Solaris Resource Manager 并不直接使用，而是出于记帐目的而由管理员使用。该值与利用率不同，所表示的是组内所有 lnode以及当前 lnode 的应计利用率。

在第二个空白行之后，liminfo(1SRM)的下面四行所显示的是与虚拟内存有关的四个字段：

Mem usage [memory.usage][memory.myusage]

这是所有附加到该 lnode 的进程的综合内存利用率。

如果所显示的是两个值，中间用斜杠（/）符号隔开，则该 lnode 是一个组头目，而第一个值是整个调度组的利用率，而第二个值只是当前用户的利用率。

Mem limit [memory.limit]

附加到该 lnode 及其成员（如果确实有的话）的所有进程所允许有的最大内存利用率。即，组内所有进程以及附加到该组的所有进程的内存利用率总计不得超过该值。注意，在这个实例中，"0"值指示没有限制。

Proc mem limit [memory.plimit]

每一进程内存限制是附加到该 lnode 及其成员的任意单个进程所允许有的最大内存利用率。

Mem accrue [memory.accrue]

内存应计值是以字节-秒钟为单位进行测量的，指示的是一段时间以来所使用的内存资源总和。

在第三个空白行之后，liminfo(1SRM)显示输出的下面四行显示的是与用户和进程有关的字段。

Processes [process.usage][process.myusage]

这是附加到lnode的进程的数目。注意，这是进程，而不是某一进程内部的计数线程。

如果所显示的是两个值，中间用斜杠（/）符号隔开，则该 lnode 是一个组头目，而第一个值是整个调度组的利用率，第二个值只是当前用户的利用率。

Process limit [process.limit]

允许附加到该 lnode 及其成员的进程的最大总数。

当前登录[logins]

该用户的同时 Solaris Resource Manager 登录会话期间的当前数目。当某个用户借助标准系统登录机制中的任意一个进行登录时（其中包括login(1)、rlogin(1)，等等），基本上任何使用 PAM 来进行鉴别并创建一个 utmp(4)条目的机制中，则该计数器减少。

如果某个用户的 flag.onelogin 标志值为设置，则只允许该用户拥有一个 Solaris Resource Manager 登录会话期间。

Last used [lastused]

该字段显示的是 lnode 最后活动的时间。通常是用户最后注销的时间。

Directory

该用户的主目录（出于方便，所显示的是来自口令映射的项目，而不是来自 Solaris Resource Manager 的项目）。

Name

db1 (finger) 信息，通常是用户的名称（出于方便，所显示的是来自口令映射的项目，而不是来自 Solaris Resource Manager 的项目）。

Shell

用户的初始登录 shell （出于方便，所显示的是来自口令映射的项目，而不是来自 Solaris Resource Manager 的项目）。

Flags

这里显示的是值为设置的标志或者 lnode 中的组。所显示的每个标志都跟有后缀字符，指示设置标志的值和方式（例如，是明确来自本 lnode (+)，还是继承 (^) 得来的）。