第 6章 SHR 排程器

Solaris Resource Manager SHR 排程器是用來控制 CPU 資源的配置。管理員可以利用資源分享的概念來輕易地控制使用者、群組以及應用程式的對 CPU 資源的相對權利。分享資源可以比做一個公司內的股份；擁有多少不是最重要的，而是與其他持股人相比之下有多少。

技術性說明

每一個 lnode 有四種與 Solaris Resource Manager 排程器有關的屬性﹕cpu.shares、cpu.myshares、cpu.usage 以及 cpu.accrue。liminfo(1SRM) 的輸出可以顯示這些屬性以及其他有用的數值。

Solaris Resource Manager 排程係藉由 SHR 排程類別來實施。這包括對 dispadmin(1M)、priocntl(1)、nice(1) 及 renice(1) 指令的支援。在系統呼叫的層級，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 之上。

• 在 init.d(4) 指令集中使用 srmuser(1SRM) 指令，以將任何精靈處理附加至一個非 root lnode 的之上。根據內定，開機指令集所啟始的任何處理都有一個有效的 root UID，而且會附加至 root lnode 之上。使用者指令容許精靈保留一個有效的 root UID，同時附加至其自身的 lnode。這樣若於任何精靈變為需要佔用大量 CPU 時，可以避免發生問題。

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

配置的配分

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，保留一個孤立的子樹。子管理員可以在自己的群組中重新建立這個遺失的 lnode，因此便取得樹先前孤立段落的控制權。

• 中央管理員可以使用 limreport(1SRM) 指令，通過內建的孤立行標識符，來辨識樹狀結構的孤立段落。然後應該立即重新附加找到的孤立行。不過 limreport 指令也可以被子管理員用來尋找孤立的子樹，以便將它們新增入其群組中，如上所述。可是這麼做可能會造成潛在的安全性顧慮。

• 建立一個新的 lnode 時，其中資料多半是零，而使大多數旗標承繼內定值。旗標多半會希望有這種效果，因為它們是用來指明裝置權限的。在建立 lnode 的時候被清除的旗標為 uselimadm 以及 admin 旗標。這樣可以防止新使用者自動取得任何管理性權限。

樹狀結構說明

下面所示的樹狀結構包括數個群組 header 以及數位普通使用者。其頂端為 root 使用者。一個群組 header lnode 則包含兩個整數，分別代表其配分值以及 myshares 屬性。另一個葉片 lnode 則包含單一整數，只代表其配分屬性的值。

圖 6-1 排程樹狀結構

計算配置的配分

目前 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 值的處理優先順序的半減期則為六秒鐘。

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

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

欲知有關 Solaris Resource Manager 資訊以及它與其他資源控制功能之間的關係，請參閱"與其他 Solaris 資源控制功能的關係"。

動態再配置

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

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

Idle lnode

Idle lnode (srmidle) 是由中央管理員所指派的 lnode，用以收取所有 kernel 的閑置 CPU 費用。在安裝時，idle 使用者（使用者名稱 srmidle）會以一個 41 的值來建立。Idle lnode 的配分應該為零，以確保其上所附加的處理只能在沒有其他作用中的處理時執行。Idle lnode 可以利用 srmadm(1MSRM) 指令加以指派。

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

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

Other lnode

Other lnode (srmother) 是由系統管理員為初始安裝之後所建立的新使用者所指派的內定雙親 lnode（其中 root 為內定的雙親 lnode）。而系統在安裝時自動建立的 other lnode 有 1 個配分的內定值，以確保其上所附加的 lnode 可以存取 CPU 的資源。

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

Lost lnode

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

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