Solaris Resource Manager 1.3 系統管理指南

第 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 屬性可用來依照使用者的雙親和作用中的同層比例分配 CPU 權利。唯有使用者擁有作用中的 子使用者時，使用者的 cpu.myshares 屬性才有意義；它可用來決定其各自的 CPU 權利比例。

舉例來說，如果使用者 A 和 B 是雙親 P 唯一的兩個子用戶，而 A、B 和 P 在群組 P 中各有一個配分（亦即 A 和 B 的 cpu.shares 設定為 1，而 P 的 cpu.myshares 也設定為 1），那麼他們各有群組總權利的三分之一的 CPU 權利。

因此一位使用者實際的 CPU 權利取決於雙親的相對權利。亦即有賴於雙親的 cpu.shares 對於其同層的相對值，以及對於祖輩的 cpu.myshares 相對值，一直上溯整個排程樹。

為了系統管理之便，附加至 root lnode 的處理不受配分屬性的限制。任何附加至 root lnode 的處理總是會取得它所需的所有 CPU 資源。

重要的是不可將 CPU 用量大的處理附加至 root lnode 之上，因為這樣做會嚴重影響到其他處理的執行。要避免此問題，請仔細考慮下列各點：

中央管理員帳號應該有自己的 UID，和超級使用者帳號的 UID 不同。登入以執行非管理性的活動時必須使用此帳號。如果需要一個超級使用者的 UID 來執行管理功能的話，中央管理員可以使用 su(1) 指令來變更 UID，同時仍然附加在其自身的 lnode 之上。
srmuser(1SRM) 指令可在 init.d(4) 指令集中用以將任何常駐處理附加到非root lnode。根據預設，開機指令集所啟始的任何處理都有一個有效的 root UID，而且會附加至 root lnode 之上。使用者指令容許常駐程式保留一個有效的 root UID，同時附加至其自身的lnode。這樣若於任何常駐程式變為需要佔用大量 CPU 時，可以避免發生問題。

不是所有排程樹中的群組標頭都需要代表實際執行處理的使用者；而且在這種時候也不需要為它們配置一個 CPU 配分。可以將此類 lnode 的 cpu.myshares 屬性設定為零來指定它們。此種群組標頭中的 cpu.accrue 屬性，依然包括其群組所有成員使用量的應付款項。

配置的配分

cpu.shares 及 cpu.myshares 屬性決定每個現用 lnode 的目前 CPU 配置配分 ，以百分比計算。未作用使用者的配分不會影響配置的配分。如果只有一位作用中的使用者，那麼該使用者會取得百分之百的可用 CPU 資源。如果只有兩位作用中的使用者，在相同的群組中有相等的配分，那麼每一個使用者將配置到百分之 50 的配分。請參見計算配置的配分以取得更多有關如何計算配置配分的資訊。

使用量及消減

每當一個附加至 lnode 的處理應付一個 CPU 循環的款項，cpu.usage 屬性便會增加。使用量屬性值會依照由使用量消減全域 Solaris Resource Manager 參數所決定的指數率來消減。使用量消減率（以秒為單位的半減期代表）由 srmadm(1MSRM) 指令來設定。

雖然所有處理都有一個 lnode，無論其目前的排程類別為何，在 SHR 排程類別之外的 lnode 始終不會被要求支付款項。

累計的使用量

累計的使用量屬性會隨著使用量屬性的增加而增加同等的量，但卻不會消減。因此它代表屬性上一次重設之後，附加至 lnode 及其成員所有處理累積使用量的總計。

有效的配分

一個 lnode 配置的配分及其 cpu.usage 屬性可以決定其目前有效的配分。Solaris Resource Manager 排程器會調整附加至一個 lnode 的所有處理優先順序，以使其工作速率與 lnode 的有效配分成比例，而與其上附加的可執行處理計數成反比。

每個處理配分優先順序 (`sharepri`)

作業系統 kernel 會為每個附加至 lnode 的處理都保持一份內部 Solaris Resource Manager 的資料。其中作為排程目的最重要的數值為 sharepri 值。擁有最低 sharepri 值的處理總是最有資格，會被優先排程在一個 CPU 之上執行。

配分配置範例

排程樹結構

下列數點與排程樹的結構有關，中央管理員必須特別注意：

排程樹是 Solaris Resource Manager 用來實施資源階層及權限控制的一種結構。如果一位子管理員獲得通常沒有存取權的排程樹的子樹控制權，他們可以在沒有中央管理員的許可下，取得額外的資源使用量及權限的存取權。要取得此種權限，其中一個方法就是管理員移除一個 lnode，保留一個孤立的子樹。
中央管理員可以使用 limreport(1SRM) 指令，通過內建的孤立行標識符，來辨識樹狀結構的孤立段落。然後應該立即重新附加找到的孤立行。
建立一個新的 lnode 時，其中資料多半是零，而使大多數旗標承繼預設值。旗標多半會希望有這種效果，因為它們是用來指明裝置權限的。在建立 lnode 的時候被清除的兩個旗標為 - uselimadm 以及 admin 旗標。這樣可以防止新使用者自動取得任何管理性權限。

樹狀結構說明

下面所示的樹狀結構包括數個群組標頭以及數位普通使用者。其頂端為 root 使用者。一個群組標頭 lnode 則包含兩個整數，分別代表其 cpu.shares 以及 cpu.myshares 屬性。枝葉 lnode 以單個整數顯示，僅用於代表其 cpu.shares 屬性值。

圖 6-1 排程樹結構

圖表顯示群組標題及其 cpu.shares 和 cpu.myshares 屬性值。標題下方的枝葉節點僅顯示其 cpu.shares。

計算配置的配分

以先前的數字為例，目前 lnode A、C 及 N 之上都附加了處理。在樹的最頂層，CPU 只需要由 A和 M 來分享，因為 W 或排程群組 W 中的任何成員都沒有任何處理。A和 M 之間的配分比率為 3﹕1，因此頂層的配置配分應為百分之 75 給群組 A，而百分之 25 給群組 M。

然後配置給群組 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 可以讓中央管理員來調整被 nice 功能影響的處理的sharepri 消減率。 srmadm(1MSRM) 指令中的pridecay 全域 Solaris Resource Manager 參數，用於設定處理之優先的消減率，其中包含普通及最大 nice 值。在普通和最大 nice 值之內的消減率可以內推，而同樣地也可以外推到最小的 nice 值。例如，普通處理的優先順序（如 sharepri）的半減期為兩秒鐘，而有最大 nice 值的處理優先順序的半減期則為 60 秒鐘。

其效果是 nice 影響下的處理會比在相同 lnode 之上的其他處理取得較小的 CPU 配分。在 Solaris Resource Manager 之下， nice 功能較無法左右不同 lnode 之上的處理執行率，除非可執行處理的佇列超出 CPU 的數目。

Solaris Resource Manager 會以特別的方式來對待擁有最大 nice 值（例如，以一個 nice -19 指令開始的值）的處理。如果沒有其他處理要求此類處理，因而即將被閑置的話，它們只會被賦予 CPU 循環。

欲知有關 nice 資訊以及它與其他資源控制功能之間的關係，請參見 nice(1) 及 nice(2SRM)。欲知有關 Solaris Resource Manager 與其他資源控制功能之間的關係，請參見 Solaris Resource Manager 與類似產品間的不同之處。

動態再配置

Sun Enterprise 伺服器的動態再配置 (DR) 功能可以讓使用者動態式地新增與刪除系統轉接板，其中包含如處理機、記憶體以及 I/O 裝置等硬體資源。Solaris Resource Manager 會記錄排程所需的可用處理機資源，並且適當地處理變更，公平地將目前可用的處理機資源重新分配給合格的使用者/處理。

因為 Solaris Resource Manager 只能控制處理的虛擬記憶體大小，而非處理及使用者所用的實體記憶體大小，DR 操作對於記憶體的效果無法對 Solaris Resource Manager 的記憶體限制檢查產生任何影響。

`srmidle` Lnode

idle lnode (srmidle) 是由中央管理員所指派的 lnode，用以收取所有 kernel 的閒置 CPU 費用。在安裝時， srmidle 和 41 UID 一起被創建。srmidle lnode 的配分應該為零，以確保其上所附加的程序只能再沒有其他作用中的程序時執行。 srmidle lnode 是使用 srmadm 指令分配的。

在開機時，預設的 idle lnode 為 root lnode。而當您轉換為多重使用者模式之後， init.d 指令集會將 idle lnode 設定為 srmidle 帳號的 lnode（如果此帳號的確存在的話）。您可以在 /etc/init.d/init.srm 指令集中指定一個不同的 lnode 來使用，以自訂這種行為。

如果 idle lnode 並非 root 的話，那麼它必須是 root的一個直接子節點。

`srmother` Lnode

其他 lnode (srmother) 是由系統管理員為初始安裝後建立的新使用者，指定為預設父代 lnode 的 lnode（其中 root 為預設父代 lnode）。而系統在安裝時自動建立的 srmother 有 1 個配分的預設值且不可變更，以確保其上所附加的 lnode 可以存取 CPU 的資源。 srmother lnode 使用 43 的 UID 建立。

srmother lnode 應該沒有資源限制，一個或更多的 CPU 配分，而且沒有特別權限。

`srmlost` Lnode

在 Solaris Resource Manager 之下，setuid(2SRM) 系統呼叫有將呼叫的處理附加至一個新 lnode 的副作用。如果附加動作的變更失敗，通常是因為新 lnode 並不存在，那麼處理反而會被附加至 lost lnode (srmlost) 之上，這是當您安裝 Solaris Resource Manager 時所建立的。如果此附件也失敗或是沒有指定任何 srmlost lnode，那麼 setuid 功能不受影響，而程序會繼續在其目前的 lnode 之上執行。

init.srm 程序檔會在轉換為多重使用者模式的期間設定 srmlost lnode。您可以在 /etc/init.d/init.srm 檔中指定一個要用的 lnode 以取代這種行為。要避免安全上的問題， srmlost lnode 應該有一個 CPU 配分，而且沒有任何特別的權限。如果您修改這些數值，請務必在變更時考慮對此使用者的要求。

srmlost lnode 由 42 的 UID 建立。