在 UNIX 启动过程中,在不同的时间点, Solaris Resource Manager 的各个侧面均被启用。其主要步骤显示如下:
在核心首次启动时,就从 /etc/system 文件加载各种参数。其中有些影响到 Solaris Resource Manager 。下面对此有详尽的描述。
随着核心继续初始化,在创建了进程0之后,但在进程1启动之前, Solaris Resource Manager 得到初始化。其中涉及加载 SHR 模块以及让 Solaris Resource Manager 对进程1(init(1M)进程)调度。这是通过启动 SHR 调度类中的 init(1M)来完成的,而不是默认的调度类。
起初,将 init(1M)进程及其所有子进程附加到替代根 lnode。
在核心完全初始化后,系统将从单用户模式过渡到多用户模式之一(通常是run-level 2 或者 3)。在本过程的早些时候,将运行/etc/init.d/init.srm 正文。该正文所进行的操作在 "启动序列事件" 中有描述,其作用在于启用常规的 Solaris Resource Manager 操作。
如果有必要在启动系统时不使 Solaris Resource Manager 活动,则可以通过将 /etc/system 文件中的 initclass 变量变成指向 timesharing (TS) 而不是 SHR 来加以实现。实现的另一简单方法就是使用 boot(1M)命令的 -a(ask)选项,这样就会提示您输入一个系统文件。对于其它提示,只需按 RETURN 键,接受默认值,一直到提示您输入系统文件名。在提示输入系统文件名的地方,输入 etc/system.noshrload(没有引导斜杠)作为响应。下面是本过程的一个示例:
注意,/etc/system.noshrload 只是 /etc/system 的一个备分副本,是在安装 Solaris Resource Manager 时生成的。如果后来又对 /etc/system 进行过编辑,则 /etc/system.noshrload 应当得到并行维护,从而使其不同之处只是 Solaris Resource Manager 所作的修改:
# diff /etc/system /etc/system.noshrload < # enable srm < set initclass="SHR" |
事件在系统启动后向多用户模式转换的过程中发生的序列,在 Solaris Resource Manager 尤其重要。下列步骤是正确建立 Solaris Resource Manager 系统的序列:
使用 srmadm(1MSRM)命令来配置和启用 Solaris Resource Manager 。此时,将打开限制数据库并启用 Solaris Resource Manager 调度器。请参阅 "借助 srmadm 启用 Solaris Resource Manager",了解到有关使用srmadm(1MSRM)来启用 Solaris Resource Manager 的信息。
指派"lost"和 "idle" lnodes。
启动 Solaris Resource Manager 守护程序。请参阅 "启动 Solaris Resource Manager 守护程序",了解到有关此步骤的信息。
在适当 lnode 上启动其它的系统守护程序。
上述进程的步骤 1到3中所使用的默认正文见于附件。
将守护程序(通常永久运行的系统维护进程)添加到某一非根 lnode 的 lnode,有特别重要的意义。附加到根 lndoe 的进程是特别调度的,将给予其所要求的所有 CPU 资源,因而不建议将任何有可能是 CPU 密集型的进程附加到根 lnode。将守护程序附加到其自己的 lnode,使得中央管理员可以为其分配一个合适的 CPU 份额。
在启动过程中,每个新的进程均会从其父进程继承其 lnode 附加状态。鉴于 init(1M)进程是附加到根 lnode 的,因而所有后续的进程也是如此。直到运行 Solaris Resource Manager 初始化正文并打开 lnode 数据库,才能将进程附加到其它的 lnode,不仅如此,还需要某个进程进行显式的 setuid(2)系统调用(诸如 login(1)),或者明显地要求 Solaris Resource Manager 附加到一个已命名的lnode,诸如 srmuser(1SRM)命令的操作。运行某一程序时设置了 setuid 文件模式位,并不导致 lnode 附加状态发生变化。
其后果是所有在系统启动过程中自动启动的系统程序,均将附加到根 lnode。这经常是不需要的,因为任何附加到根 lnode 的进程如果变为 CPU 密集型,则将严重破坏其它进程的执行。因此,建议将作为启动过程一部分而启动的任何守护程序明确地,均附加到其自己的 lnode,方法是使用 srmuser(1SRM)命令来加以调用。这不会影响其真实而有效的 UID。
这里显示的是一个可能的例子:
# /usr/srm/bin/srmuser Start in.named attached to the my_daemons lnode. |
这些行可以用于替换其启动正文中现有的对 named(1M)守护程序的调用。这需要在事先为"网络"创建一个用户帐户和 lnode。
srmadm(1MSRM)命令允许管理员对 Solaris Resource Manager 系统的操作状态和全系统的配置进行控制。典型情况是,在过渡到 run-level 2或者3的过程中,从 Solaris Resource Manager init.d(4)正文 /etc/init.d/init.srm 内部使用该命令,从而确保每次启动系统时所有参数均设置了适当的值,并且确保在用户可以访问系统之前将 Solaris Resource Manager 系统启动。srmadm(1MSRM)命令还用于管理全局 Solaris Resource Manager 参数。请参考 srmadm(1MSRM)手册页,就可以获得一个可以借助 srmadm 进行设置的参数的列表。srmadm(1MSRM)命令由 Solaris Resource Manager 的init.d(4)正文发出,用于:
打开限制数据库。直到目前为止,所启动的任何进程均被附加到替代根 lnode。无论 Solaris Resource Manager 的操作状态如何,替代根 lnode 用于确保总有一个 lnode 可以用来连接进程。正是出于这个原因,在启动任何非根进程之前打开限制数据库十分重要。当限制数据库打开时,替代根 lnode 中的利用率属性的值就被添加到其在真实根 lnode 中的对应部分。该作法的一个局限就是,利用率所发生的任何净减少都不会计算在内。这就确保在打开限制数据库之前所发生的利用率改变并不会废弃。
启用限制强制执行。
设置对 Solaris Resource Manager SHR 调度器进行控制的参数,例如,利用率衰变速率。
启用 Solaris Resource Manager 调度器。在此之前,SHR 调度类中的进程是以简单的不分先后方式加以调度的,在 Solaris Resource Manager 系统内部设置的 CPU 权利不起作用。
参考 "借助 Srmadm 设置全局 Solaris Resource Manager 参数",了解 srmadm(1MSRM)命令的一些常见调用方法。
limdaemon(1MSRM)程序是 Solaris Resource Manager 的用户模式守护程序。通常是在向 run-level 2 或 3过渡时作为 Solaris Resource Manager 的init.d(4)正文的最后步骤加以调用的。不要将其与 srmgr 系统进程(在 SYS 类中)混淆,后者是由核心起动的。下面的ps(1)列表显示了这两个进程:
# ps -efc | egrep 'limdaemon|srmgr' root 4 0 SYS 60 18:42:14 ? 0:05 srmgr root 92 1 SHR 19 18:42:32 ? 0:41 limdaemon |
接收通知消息并将其提交给目的用户的终端
接收登录和注销通知消息,对当前正在进行的所有 Solaris Resource Manager 登录会话期间保持一个精确的记录
周期性地为当前 Solaris Resource Manager 登录会话期间正在进行之中的所有用户更新连接时间利用率(可选)
监测业已达到其连接时间限制的用户,并在一段宽限间隔过后终止其进程,将其注销(可选)
借助 syslog(3)将所有的操作记录到 syslogd(1M)
当得知 Solaris Resource Manager 登录会话期间时,limdaemon 就监视所有用户的终端连接时间,并将此与其连接时间限制进行核对。当几乎达到其连接时间限制时,就向其发送一条通知消息。一旦达到到期时间,就给予一段宽限时间,然后就终止其所有的进程,并将其注销。
limdaemon 程序使连接时间利用率衰变。如果使用了连接时间限制,就必须对终端设备类别进行利用率衰变。请参考 "使用 limdaemon 选项",了解有关可以用于控制 limdaemon 性能的命令行选项的细节。