基於系統管理的目的,附加至 root lnode 上的程序幾乎都可取得其所需的所有 CPU 資源。因此如果有一個需要大量 CPU 的程序附加至 root lnode 上的話,它會完全佔用一個 CPU,而使其他 lnode 上的程序變得緩慢甚而完全停止作用。
請仔細考慮下列數點以防止上述的問題發生﹕
管理員應該登入一個他們自己的 lnode 來進行一般性的作業,而不是附加至 root lnode 之上。如果他們基於某種原因必須附加至 root lnode 的話,應該注意不要使用任何會佔用太多 CPU 資源的應用程式,如編譯程式等。要在不附加至 root lnode 的情況下使用一個超級使用者的 UID,管理員可以使用 su(1) 指令。
init.d 指令集可以改成使用 srmuser 程式,以便將所有常駐程式附加到它們自己的 lnodes,從而使它們附加(透過承繼)到 root lnode。然而此類解決方法不能被例行的建議。因為非常大數量的檔案需要被編輯,這可能是一個負擔,而且本實行不能禁止稍後將修補程式整合到系統的能力。有一個不需要本工作被手動執行的解決方法已在調查中。
對於比 1.0 新的 Solaris Resource Manager 發行版,在 /usr/srm/unsupport 目錄中提供的指令集 sbin_rc2,可用於部份地解決這個問題。
一個作為 setuid-root 執行的程式不會自動附加至 root lnode 之上。一般而言,處理仍然附加至建立該處理的雙親的 lnode 之上,只變更其有效 UID。
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 類別一樣。
假如超級使用者所執行的程序包含程式碼,而且這程式碼使用 priocntl(2) 系統呼叫,而不以 setpriority(3C) 程式庫常式來調整處理優先順序的內碼,那麼它們會將目標處理移入另一個排程類別中(通常是 TS)。因為 setpriority 程式庫常式內碼可以使 SHR 的 priocntl 介面與 TS 的介面二進位相容,因此能避免問題發生。指令: -c 可以使用 ps(1)-d 可以使用 priocntl(1) 選項來顯示程序的排程類別。
超級使用者權限處理也會發生同樣的難題,它堅持使用 priocntl(2) 來管理處理的排程類別成員身份。