適用於 Solaris 2.6 的 Solaris Resource Manager 1.0 系統管理指南(SPARC 平台版)

第 9章 解決難題

特別包含本節以協助管理員診斷 Solaris Resource Manager 的操作問題。

使用者無法登入

沒有任何上述所列的 Solaris Resource Manager 限制可以應用至 root 使用者。

使用者未被告知達到限制

在 Solaris Resource Manager 的一般性操作期間,登入的使用者會在到達限制時收到通知訊息。使用者可能並不清楚造成其問題的原因,只覺得系統似乎有點問題。不過系統管理員一定會接到有關限制的通知。

通知訊息是由 Solaris Resource Manager 精靈程式 limdaemon 來負責遞送。管理員可以利用數種方法來查驗通知訊息是否未被遞送出去﹕

無法變更使用者群組

sgroup 屬性決定 lnode 在排程樹中的雙親。此階層結構可用來管制資源使用量並且排程 CPU 的資源使用。因此在修改 sgroup 屬性時必須注意幾種安全上的問題,以避免無法補救的錯誤發生,並且不要因規避問題而繞過 Solaris Resource Manager。

要修改 sgroup 屬性,使用者需要下列其中一種權限﹕

孤立的 lnode 無法稱為其他 lnode 的雙親。請參閱"孤立的 Lnode"

損壞的限制資料庫

如果限制資料庫發生損壞的現象,對管理員來說是極大的麻煩。因為幾乎沒有任何一種徵象能用以斷定限制資料庫是否已經損壞,不過可以藉由確認幾種跡象來決定損壞的限制資料庫。

如果證實已經損壞,管理員應該回復限制資料庫尚未損壞的版本及相符的設置。如果限制資料庫損壞的範圍並不大,管理員也許能夠保存其他所有 lnode 的內容,然後使用 limreport(1SRM)limadm(1MSRM) 指令,重新將它們載入一個新的限制資料庫中。

欲知更多有關偵測與修正損壞的限制資料庫方面的資訊,請參閱"限制資料庫損壞"

終端機連結時間並未更新

這個問題最可能的原因就是 limdaemon(1MSRM) 程式沒有執行。limdaemon 會定期性地為目前所有登入的使用者更新終端機裝置類目中的使用量以及累計的屬性。一般而言,它會被 Solaris Resource Manager init.d(4) 指令集啟始。

使用者經常超出限制

其數種可能的原因如下﹕

系統執行緩慢

Root Lnode 之上的處理

基於系統管理的目的,附加至 root lnode 上的處理幾乎都可取得其所需的所有 CPU 資源。因此如果有一個需要大量 CPU 的處理附加至 root lnode 上的話,它會完全佔用一個 CPU,而使其他 lnode 上的處理變得緩慢甚而完全停止作用。

請仔細考慮下列數點以防止上述的問題發生﹕

一個作為 setuid-root 執行的程式不會自動附加至 root lnode 之上。一般而言,處理仍然附加至建立該處理的雙親的 lnode 之上,只變更其有效 UID。

CPU 資源不受 Solaris Resource Manager 的控制

Solaris Resource Manager 只控制 SHR 排程類別中的處理所使用的 CPU。如果其他排程類別提出優先順序較高的過度要求,特別是即時 (RT) 及系統 (SYS) 兩種類別的話,那麼 SHR 就只能排程剩餘的 CPU 資源。

RT 類別的使用會與 Solaris Resource Manager 軟體控制系統的功能相衝突。即時處理會取得完整的系統存取權,特別是因為這樣它們才能做出即時的回應(速度大約是數百微秒)。SHR 類別中執行的處理優先順序顯然會比即時類別中的任何處理都來得低,而 Solaris Resource Manager 又沒有即時處理的控制權。即時處理會輕易地佔用所有可用的資源,幾乎不留給 Solaris Resource Manager 任何資源好配置給剩餘的處理。

值得一提的是,有一種完全 在 SYS 類別中執行的系統服務,稱為 NFS 伺服器。Solaris Resource Manager 無法控制 NFS 精靈,因為它們在 SYS 中執行。Solaris Resource Manager 產品配置處理機資源的功能,在提供密集 NFS 服務的系統之上可能效果不彰。

當處理正在執行 kernel 內碼(在一個系統呼叫之內)時,不適用一般性的時間分割強取規則。大多數的系統呼叫只能在到達一個強取點之前完成有限的工作量。不過如果有許多更密集的系統呼叫在影響系統的話,可能會造成整體回應效率的降低,並且超出排程類別的控制範圍之外。

如果系統缺乏可用的真正記憶體,那麼隨著缺頁率的增加及處理交換的增加,會造成 I/O 的瓶頸而導致 CPU 的 kernel 佔用增加。在 I/O 上等待太長的時間可能會喪失 CPU 的執行功率。同樣地,這也在排程類別的控制範圍之外。

SHR 排程類別是一種分時 (TS) 排程器。它和 TS 以及 IA 排程器一樣使用相同的全域優先順序範圍。 SHR 不適合用來與 TS 和 IA 混合使用,除非是用於將所有處理移入或移出 SHR 類別時。以 SHR 和 TS 類別的混合處理來進行系統操作,會使這兩種類別排程行為的品質降低。因此 Solaris Resource Manager 不允許非 root 的處理將自己或其他處理移入 TS 或 IA 類別。RT 類別使用一種代用優先順序範圍,而且可以和 SHR 類別一起使用,就好像使用 TS 和 IA 類別一樣。

如果 root 所執行的處理包含直接使用 priocntl(2) 系統呼叫,而不以 setpriority(3C) 程式庫常式來調整處理優先順序的內碼,那麼它們會將目標處理移入另一個排程類別中(通常是 TS)。因為 setpriority(3C) 程式庫常式內碼可以使 SHR 的priocntl(2) 介面與 TS 的介面二進位相容,因此能避免問題發生。-可以使用ps(1) 的 c 選項或是 -priocntl(1) 的 d 選項 來顯示處理的排程類別。

root 權限處理也會發生同樣的難題,它堅持使用 priocntl(2) 來管理處理的排程類別成員身份。

未預期的通知訊息

受到達到限制影響的任何使用者都會收到通知訊息。因此如果到達一個群組限制之後,群組 header 和在排程階層之下的所有使用者都會收到一個通知訊息。

如果一位使用者附加至另一個 lnode 之上,就可能會達到某種限制。使用者雖然沒有收到通知訊息,但是所有其他的使用者都會收到此訊息。對受到限制的群組而言,問題的原因可能不夠明顯。

孤立的 Lnode

孤立 lnode 的定義就是沒有雙親 lnode 存在的 lnode。Solaris Resource Manager 管理員必須擔心這一點,因為 Solaris Resource Manager 不允許處理附加至排程樹中任何孤立或有孤立祖先的 lnode。

Kernel 會檢查 sgroup 屬性的變更,以防止排程群組雙親因無效的更改而建立孤立行。

孤立一個 lnode 的主要後果是,它無法再附加任何處理。既然無法連結任何處理,該 lnode 便無法用於登入。因此使用對應帳號來登入的嘗試都會失敗。

管理員偵測孤立 lnode 的簡單方法就是使用有內建孤立行標識符的 limreport(1SRM) 指令。指令

% limreport orphan - uid sgroup lname

會列出 UID、排程群組雙親以及有孤立 lnode 的使用者登入名稱。sgroup 屬性可以用來決定哪一個 lnode 位於樹形結構孤立段落的頂端。

找到一個孤立 lnode 之後,管理員應採取的第一步便是找出排程樹孤立段落的頂端,因為這個 lnode 需要被重新附加。如果沒有正確地識別出孤立段落的頂端,那麼便只有孤立段落的一部份會被附加至樹形之上。

一旦找到孤立段落的頂端之後,擁有充份權限的管理員便可以使用 limadm(1MSRM) 來將頂端孤立 lnode 的 sgroup 屬性設定為排程樹中的一個有效的 lnode。因此孤立 lnode 會被重新附加至樹形結構,成為有效的 lnode 所帶領的群組成員。limadm 可以確認將要應用的新排程群組雙親可以被啟動,因而確保被變更的 lnode 將不再是孤立的。

另外管理員還可以建立一個新的使用者,讓其 UID 等於孤立 lnode 的 sgroup 屬性中的 UID。這樣便能自動重新附加樹形結構的孤立段落。

群組迴圈

當一個 lnode 成為作用中的時,從其雙親一直上到 root lnode 也都會一起被啟用。這時如果發現稍早已經遇到其中一個 lnode 的雙親,那麼 kernel 就發現了一個群組迴圈。

如果限制資料庫已經損壞,便可能會發生群組迴圈,其中 lnode 的其中一個祖先也會是它的子。kernel 會特意地打破迴圈而自動將它連結至排程樹,然後將其連結為 root lnode 之下的一個群組。因此位於迴圈與排程樹連結的那一點的 lnode 就會變成最頂層群組的 header。如此一來,此群組的成員很可能會承繼原本所沒有的權限或更高的限制。

原因

設定排程群組雙親時可以藉由 limadm(1MSRM) 來防止群組迴圈的產生。生成群組迴圈的唯一原因是由於限制資料庫出現損壞的情況。這是一個嚴重的問題,而且可能會造成 Solaris Resource Manager 一些其他的問題,因為限制資料庫對其操作而言非常重要。

後果

當 kernel 發現一個群組迴圈之後,它會無聲地將迴圈中的一個 lnode 直接附加在 root lnode 的下方。因為迴圈沒有開頭或結尾,所以它無法決定哪一個才是最頂層的 lnode。

修正

此種排程樹結構的問題會自行修正,因為 kernel 會將 lnode 附加至 root lnode 之上。因為迴圈是由其上的任意一點被附加的,管理員必須決定要將 lnode 附加在何處,也必須檢查迴圈中其他每位成員的附加點。

您可以列出所有 root lnode 的子 lnode 來查看自動群組迴圈修補的結果。指令

% limreport 'sgroup==0' - uid lname

會列出以 root lnode 為其雙親的所有 lnode。如果任何列出的 lnode 不應該是 root lnode 的子,它們可能是被附加在 root lnode 下方的群組迴圈頂端。

管理員在找到群組迴圈之後最擔心的問題就是,如果群組迴圈的確是由於限制資料庫發生損壞而產生的話,那麼會有更嚴重的問題發生。如果管理員懷疑限制資料庫有損壞的情況,最好是馬上查驗該檔,以確定它是否已被損壞,然後採取適當的補救措施。請參閱"恢復故障"中,就如何偵測與修正損壞的限制資料庫所做的詳細說明。

恢復故障

當 Solaris 系統發生故障時,管理員必須考慮許多問題。不過如果當時在使用 Solaris Resource Manager 系統的話,還必須額外考慮其他幾點﹕

以下各節會詳細討論這幾個方面,並且在適當時提出處理問題的建議。

限制資料庫損壞

Solaris Resource Manager 非常努力維護限制資料庫,損壞不太可能發生。然而如果的確有損壞發生的話,會對管理員帶來嚴重的問題,因為這個資料庫是 Solaris Resource Manager 操作的基礎。因此應該仔細調查任何潛在的損壞,並且在偵測到之後立即加以處理。

徵兆

沒有任何一種徵兆可以確切地判定限制資料庫已經遭受損壞,不過可以藉由確認幾種跡象來決定損壞的限制資料庫﹕

如果管理員懷疑限制資料庫中出現任何損壞,最佳的偵測方法就是使用 limreport(1SRM) 來要求一份 lnode 清單,其中應該在某個範圍之內的屬性值忽然變為在範圍之外。這個指令也可以用來列出那些 flag.real 為 clear 的 lnode。這就表示其密碼映射中的帳號沒有 lnode。

補救辦法

如果證實已經損壞,管理員應該回復限制資料庫尚未損壞的版本及相符的設置。如果限制資料庫損壞的範圍並不大,管理員也許能夠保存其他所有 lnode 的內容,然後使用limreport(1SRM)limadm(1MSRM) 指令,重新將它們載入一個新的限制資料庫中。如果找不到最近的限制資料庫副本的話,這可能是一個較理想的方法,新的限制資料庫現在會包含最近的使用量及累計屬性。管理 lnode 一節中包含儲存與回復限制資料庫程序的相關資訊。如果只是遺失 lnode 這種簡單的問題的話,只要使用 limadm 指令來重新建立它們便可。

limdaemon 使連結時間遺失

如果 limdaemon(1MSRM) 基於任何原因而終止,所有目前登入的使用者便不會被收取任何連結時間使用量的款項。再者,重新啟動 limdaemon(1MSRM) 之後,任何登入的使用者都會繼續免費使用該終端機。這是因為精靈有賴於 login(1) 所遞送的登入通知,在它用來計算連結時間使用量的內部結構中,建立一個 Solaris Resource Manager 登入階段作業記錄。因此,每當它啟始之後,在接到第一個通知之前,都不會建立任何 Solaris Resource Manager 登入階段作業。

如果limdaemon 的終止是由於系統故障的話,這通常不是什麼大問題,因為故障也會導致其他處理終止。那麼直到系統被重新啟動之前,登入階段作業也無法恢復執行。

如果 limdaemon(1MSRM) 是因為其他原因而終止,管理員有兩種選擇﹕

  1. 立即重新啟動精靈,然後忽略已經登入的使用者遺失的終端機連結時間應付款項。這表示一位使用者可以不斷地免費使用一部終端機,直到被發現而登出為止。

  2. 將系統帶回單一使用者模式後再回到多重使用者模式,以確保終止目前所有的登入階段作業,而使用者必須在重新啟動精靈之後才能再次登入。