Solaris下的性能與調整[ZT]
http://www.chinaunix.net 作者:C.Arthur 發表於：2004-03-19 19:39:20
1. 着手性能問題
2. 性能監測
2.1. 從暴露出來的問題開始
2.2. 知道你的系統在正常情況下會怎樣
2.3. 尋找性能瓶頸
3. 一些常見問題和一些建議
3.1. 64位的運算與容量能帶來什麼
3.2. 空閒內存
3.3. 優先內存頁面調度
3.4. 隱私的共享內存（ISM-Intimate Shared Memory）
3.5. 與共享內存有關的交換空間設置
3.6. 進程間通信（IPC）的參數
當一個系統運行緩慢性能下降的時候，很難知道原因是什麼。是內存泄漏，磁盤子系統瓶頸，還是某個特定應用程序在可擴展性方面有限制？有一些途徑可以發現和了解引起性能問題的根源，並且有可能消除它。
本文給出了從哪裏入手的一些建議。文中介紹瞭如何着手性能方面的考慮以及如何定位常見的性能瓶頸，還介紹了與性能密切相關一些概念，比如私有的共享內存（ISM-Intimate Shared Memory）與優先內存頁面調度。文章重點是放在Solaris 2.6, 7, 和8 操作環境下。
1. 着手性能問題
性能，或許比計算機系統其它方面的行爲更需要有通盤的考慮。爲了識別來自一個或多個組件的問題根源，必須要採取結構化的方法。
實際的結果是，解決性能問題過程中最重要的一個部分是定義你正在試圖解決的問題。從實際應用的方面來講，這意味着定義一個操作或者測試用例，從而可以：
A) 知道系統當前有多快。
B) 知道系統需要快"X"倍；或者知道系統曾經在不同環境下快過"X"倍。
設置基線是開始的第一步。性能分析是由簡單明確地定義所需解決的問題開始的自上而下的一個過程。如果你想要一個系統運行得快一些，你仍然需要定義這個系統的哪些屬性是你想要改進的，以及哪些代價是你可以接受或者不可以接受的。除非你能夠明確地描述出問題症狀/機會，想要識別出問題的根源只會是碰運氣。
性能分析很象是偵探工作，我們通過證據和觀察建立事實依據，非常小心不要陷入預先想象的與事實不符的結論中——只有在具備非常壓倒性的證據時才確認猜想。
對所有假設都要懷疑。其他人聲稱的事實實際上只是個可能正確也可能不正確的假設。如果這個假設是錯誤的，你可能會是在不正確的依據下工作，從而得出不正確的結論。
這裏有一些警告。Solaris操作環境在大多數情形下對於工作負荷的自我性能優化都是很好的。發行版本越新，需要手工做的性能優化就越少。性能問題的根源經常被發現是因爲一個試圖優化性能的行爲引起的。首先需要注意應用程序，最後纔是操作環境。
任何對系統配置的更改，比如象內存大小和磁盤佈局這樣的性能設置，都應該檢查其當前的正確性。同樣，一個帶參數的系統升級也有可能對新操作環境的性能帶來影響。
2. 性能監測
2.1. 從暴露出來的問題開始
什麼操作使你看到性能問題的症狀？
比如說，是特定類型的數據庫查詢，文件或網絡操作比你期望的慢？在給出測試用例方面你能把操作步驟做到多具體，例如一個SQL查詢或者30行的C程序？
最大程度利用你的知識儘可能準確地說明“什麼地方出了什麼問題”以定義你的問題。良好的問題說明的例子就像這樣：
一個SQL查詢在VXFS上比在UFS上要花兩倍的時間。
SVR4消息隊列操作在操作環境版本A上比在操作環境版本B上要多花百分之30的時間。
登錄進系統A比登錄進系統Y多花三倍的時間。
一個問題說明不應該包括解決方法或者是可能的解決方法。
在大部分的時候，對問題有一個清晰的說明就意味着完成了解決問題過程的一大半了。在對你試圖解決的問題進行說明的時候考慮到用戶觀點的因素也很重要，這意味着要從應用程序的角度來看。這和人們的天性相反，人們總是通過實驗試圖去證明或者證僞一個可能的原因，而不是依據觀察得到的事實來評估一個原因的可能性程度。
不恰當的問題說明就象這樣：
mpstat的"wt"列表明等待時間過多。
用戶任務花時間太長。
一個系統和它的應用程序的功能正確性問題與性能問題之間的邊界往往是一個灰色地帶。整個系統掛起與進程掛起的問題不在本文討論範圍之內。如果你懷疑係統的功能不正確，而不是性能問題，那麼給你的SUN解決方案中心打電話以找到一個解決問題的方法。高性能系統的前提是它的功能首先要正確。
作爲你積極的維護計劃的一部分，檢查/var/adm/messages中有沒有比如磁盤重試之類的硬件問題或者有沒有額外的消息產生也是很有價值的。
察看系統的歷史信息也非常有價值；如果你的系統曾經有過更好的性能，畫一條時間曲線詳細記錄何時第一次發現性能變差以及從什麼時候開始性能一直很差。
2.2. 知道你的系統在正常情況下會怎樣
保存你的系統是如何正常運轉的樣例是一個好主意。你可以很容易地收集和保存每月的性能數據，比如：
*stat類：vmstat, mpstat, iostat, vxstat
sar
ps的輸出以顯示哪些進程在運行 (在Solaris 8操作環境下是prstat)
另外，有不少商業的和無支持的產品都可以用來做性能監測。一個免費的無支持的可選產品是SE Toolkit（要獲得其各種版本的信息，請看Sun Performance SE Toolkit page）。SE Toolkit報告磁盤活動、CPU利用情況、TCP和網絡連接、內存，以及其他更多信息。在我們的經驗裏，它安裝方便，不需要重啓系統，並且生成容易理解的圖形顯示。
很多這類產品都存在一個共同的問題，就是對不同的硬件配置有不同的門限值。例如，特定的門限值對於400-MHz的系統可能顯得太過，會讓這個系統慢得象是在爬一樣，但是對於一個900-MHz的系統卻可能是可以接受的。
2.3. 尋找性能瓶頸
一旦你已經定義了需要解決的性能問題，下一步驟就是縮小範圍到瓶頸產生的地方。
這個階段有必要問這樣一些問題：
應用程序能告訴我它看到哪些是瓶頸？拿Oracle作例子，一個Oracle數據庫管理員應該知道BSTAT/ESTATS是什麼以及如何運行和理解它們。還是那句話，從應用程序的角度來看問題，BSTATS/ESTATS可以顯示限制了Oralce性能的瓶頸，這可以作爲進一步分析的指導。
大部分的時間花在哪裏，是內核還是用戶進程？通過vmstat、mpstat、sar、ps、prstat可以回答這個問題。
具有相近類型的所有資源是否同樣繁忙？這個問題的意義在於尋找資源的不平等分佈。比如，一個磁盤可能是瓶頸所在，或者一個CPU會比其他CPU更忙。對CPU，看mpstat。對磁盤，用iostat。
哪個或哪些進程在使用最多的資源？用這些命令可以看到使用CPU和內存最多的進程：
ps -eo pid,pcpu,args | sort +1n
CPU百分比
ps -eo pid,vsz,args | sort +1n
K字節的虛擬內存
/usr/ucb/ps aux |more
輸出被排序，使用CPU和內存最多的進程排在上面。
Solaris 8操作環境提供了prstat，它給出CPU和內存使用情況的一個動態註解。prstat -cvm的輸出結果非常有用。
我們現在來看看怎用使用一些常見的Solaris命令來開始性能分析。
2.3.1. vmstat - 使用vmstat命令
vmstat命令是簡單的。這裏我們可以看到一個對於正在執行的應用程序，CPU能力不足的例子。
% vmstat 15
procs memory page disk faults cpu
r b w swap free re mf pi po fr de sr m0 m1 m2 m3 in sy cs us sy id
45 0 0 2887216 182104 3 707 449 6 455 0 80 2 6 1 0 1531 5797 983 61 30 9
58 0 0 2831312 46408 5 983 582 56 3211 0 492 0 0 0 0 1413 4797 1027 69 31 0
55 0 0 2830944 56064 2 649 656 3 806 0 121 0 0 0 0 1441 4627 989 69 31 0
57 0 0 2827704 48760 4 818 723 6 800 0 121 0 0 1 0 1606 4316 1160 66 34 0
56 0 0 2824712 47512 6 857 604 56 1736 0 261 0 0 1 0 1584 4939 1086 68 32 0
58 0 0 2813400 47056 7 856 673 33 2374 0 355 0 0 0 0 1676 5112 1114 70 30 0
60 1 0 2816712 49464 7 861 720 6 731 0 110 7 0 3 0 2329 6131 1067 64 36 0
58 0 0 2817552 48392 4 585 521 0 996 0 146 0 0 0 0 1357 6724 1059 71 29 0
vmstat輸出的第一行總是可以忽略。在"procs"下面標着"r"的一列是等待獲得CPU的進程運行隊列中的進程數。"id"列是CPU空閒時間。這臺機器沒有足夠的CPU資源以滿足進程運行的需要，這可以從它的大部分CPU時間花在用戶空間裏看出來(看"us"列)。
這裏有兩種辦法可供採用——第一，增加更多的CPU，或者第二，對應用程序的代碼作性能分析看看是不是應用程序的某部分可以優化。對代碼片斷作優化可能會需要非常大量的努力——而且有時候收到的效果很少。在關係到時間的時候，最好在考慮你可能的“投資回報”時現實一點。
2.3.2. mpstat -使用mpstat命令
mpstat命令報告每個處理器的統計信息，表格中的每一行代表一個處理器的活動情況。
$ mpstat 5
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 20 0 3592 3350 2338 1355 43 184 285 0 4578 9 6 1 84
1 19 0 304 465 283 2139 135 398 140 0 6170 9 6 1 85
2 25 0 352 507 295 2153 158 433 183 0 7508 12 7 1 81
3 26 0 357 513 302 2082 155 425 181 0 7460 12 7 0 81
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 3 0 3879 3773 2754 1832 61 322 339 0 3424 12 7 0 81
1 2 0 555 544 264 3040 197 670 112 0 4828 15 6 0 78
2 11 0 188 595 269 3141 219 738 121 0 5291 18 6 1 75
3 65 0 185 585 279 2660 211 673 110 0 5420 22 9 0 69
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 6 0 4028 3633 2620 1695 51 287 343 0 2857 12 8 0 80
1 7 0 150 545 265 3044 196 663 117 0 4374 14 4 0 81
2 14 0 226 602 279 2823 225 707 103 0 4715 22 4 1 73
3 2 0 125 600 282 2810 230 699 118 0 4665 18 4 0 78
mpstat可以確定每一個CPU都在花時間做什麼：比如，分配給系統、用戶、等待、空閒時間、系統調用、鎖競爭、中斷、錯誤、交叉調用。
有關每一列的詳細含義請看mpstat(1M)的手冊頁。
2.3.3. iostat -使用iostat命令
iostat命令報告磁盤的使用情況。表格中的每一行代表一個磁盤的活動信息。常用的選項有這些：
選項
說明
N
按cXtYdZ格式指定磁盤。
X
報告擴展統計信息。
z
這個選項在Solaris 8操作環境中是新的。它使得在採樣間隔中沒有磁盤活動的那些行被省略掉，這樣可以讓輸出簡短一些並且突出那些有活動的磁盤。
p和P
報告分區前（per-partition）的I/O統計信息，當察看內存交換設備的時候有用。
E
對於找出產生錯誤的磁盤有用。
表1：iostat的選項
iostat也可以透過NFS報告磁盤活動，不過可能產生比較長的報告。
2.3.4. truss -你的朋友
truss(1M)工具執行制定的命令並且生成一個追蹤記錄，包括它執行的系統調用、接收到的信號、導致的機器錯誤（traps/interruptions——譯者注）。
truss也可以用來追蹤一個正在退出的進程。這是一個非常有用的工具，可以定位應用程序向內核請求了哪些變慢了或者是被過度使用的資源。
如果你不瞭解truss，那麼可以看看手冊頁並且試一試。-m選項對於顯示例如頁面錯誤這樣的錯誤非常有用。-c選項可以給出這樣一個彙總信息：
系統調用
錯誤
信號
在每一類型系統調用上累計的時間
失敗的系統調用數目
2.3.5. lockstat -資源競爭
內核鎖可以保護對數據結構的多重更新，並且控制對諸如磁盤緩存、網絡緩存、各種內核緩存這些資源的訪問。
lockstat執行一個命令，報告在命令執行期間所有內核鎖的活動情況，不論請求鎖的是哪個進程或設備。請看lockstat(1M)的手冊頁。-s 10選項報告在每一個鎖上進行競爭的內核線程棧。
2.3.6. trapstat -運行時的陷阱統計
trapstat是一個在運行着普通Solaris內核的UltraSPARC?處理器上提供運行時陷阱（trap）統計信息的工具。對於I-TLB和D-TLB未命中，trapstat能夠可選地顯示花在操作系統TLB未命中處理程序中的時間量。對於中斷向量陷阱，trapstat能夠可選地顯示中斷設備。
2.3.7. gprof -應用程序性能分析
對於C、C++和FORTRAN應用，試試用-xpg選項編譯，並且在會產生性能問題的典型負載下運行這個程序。對生成的tmon.out文件執行gprof。這可以顯示出該應用程序大部分的時間花在哪裏。
Forte[tm] TeamWare (以前的Sun WorkShop[tm] TeamWare) 有很多有用的工具，比如用圖形化的方式表示應用程序的時間都花在哪裏的分析工具。要想了解更進一步的信息，請看Forte TeamWare文檔以及Rajat Garg與Ilya Sharapov的Sun[tm] BluePrints書籍，應用程序的優化技巧：高性能計算（Techniques for Optimizing Applications: High Performance Computing）.
2.3.8. proc工具
proc是一個利用/proc的特性來報告比如這樣一些進程屬性的實用工具：
pstack -調用棧
ptree -進程關係樹
pfiles -打開的文件描述符列表
pldd -正在運行中的進程使用的動態鏈接庫的列表
更多信息請看proc(1)的手冊頁。
3. 一些常見問題和一些建議
3.1. 64位的運算與容量能帶來什麼？
從性能的角度看，可以運行64位應用程序的能力有兩大好處。首先是更大規模的問題能夠利用更大的進程地址空間獲得有效解決。其次是整數運算可以使用64位的寄存器和指令。
整體來說，因爲代碼中的指針和數據結構都更大了所以程序也稍微變大一些。反過來，這意味着CPU的緩存也很有可能沒有足夠的緩存行，那些在32位環境下就能夠運行得很好的程序可能會稍微有一點慢。
內核線程棧是16Kb而不是8Kb，不過產生的效果經常是可以忽略的。
3.2. 空閒內存
檢查一個Solaris系統以確定還有多少空閒內存一直以來都是個容易引起混淆的地方。
對於Solaris 8操作環境之前的版本，要想察看是否內存不夠，是不依賴於"free"列或者"sr"列的。在"fr"列中的值並不能指示內存缺乏。頁面緩存一直保留住頁面以備再次需要用到它們。虛擬內存子系統只在需要的時候才收回內存。
在SunWorld文章與SUN性能與調整——Java[tm]與Internet（Sun Performance and Tuning - Java[tm] and the Internet）中這個題目已經被寫了很多了。爲了確定是否有內存不足的情況存在，同時檢查第12列("sr"，也就是掃描率)和交換分區的磁盤I/O流量(用iostat -P)。如果大量的I/O活動由文件系統產生並且需要運行頁面掃描程序爲I/O釋放頁面，"sr"列會有比較大的數值。
只有在空閒鏈表縮短到一個門限值 (lotsfree，以頁面爲單位)以下，pageout掃描程序才運行。任何非活動的並且沒有被鎖在內存中的進程或文件頁面都可能被換出。freelist的大小看上去會縮短並保持在那個數值(lotsfree)。當freelist的數量下降到lotsfree門限以下的時候，頁面守護進程將啓動，掃描需要從頁面緩存以及已退出和空閒的進程中回收的內存。沒有辦法能夠讓"空閒"值增長到這個門限以上很多，因爲沒有辦法讓頁面掃描程序在這個門限之外回收內存。讓頁面保留在頁面緩存中比把它們不必要地放到空閒鏈表中更有效率。
Solaris 8操作環境在segmap驅動程序內實現了一個更爲有效的算法給I/O提供所需的頁面。vmstat中的"fr"列確實反映了空閒並且沒有被頁面緩存所使用的內存。-p選項被加到vmstat中，用來給出更準確的頁面調度行爲細節。
對於單獨的進程，pmap命令報告單獨進程的內存空間佈局情況(-x選項比較有用)。
3.3. 優先內存頁面調度
優先內存頁面調度是在Solaris 7操作環境引入的，並被向後移植到了Solaris 2.6操作環境(內核補丁105181-XX)和Solaris 2.5.1操作環境(內核補丁103640-XX)。這兩個補丁的最近版本可以在SunSolve Online[sm]找到。
優先內存頁面調度提供了一種改進的頁面調度算法，從而在文件系統被使用的時候可以明顯地改善系統的響應速度。優先內存頁面調度引入了一個新增加的名詞，cachefree。頁面調度參數現在有這些：
minfree < desfree < lotsfree < cachefree
缺省情況下這個新功能在Solaris 2.5.1, 2.6, 和7操作環境下是關閉的，所以在有明顯頻繁內存調度的系統上允許這個功能就很重要。當priority_paging沒有被允許的時候，cachefree被置爲與lotsfree一樣。當它被允許的時候，缺省情況下cachefree被設置爲lotsfree的2倍。
調整這個參數趨於使工作站系統上窗口間切換起來更快，這對於需要從文件系統中把大文件讀入內存的運行數據庫的系統是很大的幫助。在通過文件系統執行大量I/O操作的系統上，對於擁有大量數據集的計算密集型任務，百分之幾百的速度提高都曾經有過。
Solaris 8操作環境採用了一種不同的算法，消除了以前版本中頁面掃描程序必須掃描內存以供給segmap驅動程序來存放I/O的限制因素。segmap不再需要的所有內存頁面都被放到一個可以立即重用的鏈表中。不要在Solaris 8操作環境中設置priority_paging。並且，Solaris 8操作環境應該不需要手工調整虛擬內存參數，除了在大系統中把fastscan和maxpgio設置到高一些的值會有益。
更多關於優先內存頁面調度的信息，請參考下面這些：
Sun性能、優先內存頁面調度FAQ
文檔17946: 在2.5.1+中針對優先內存頁面調度的新的內核可調整項
3.4. 隱私的共享內存（ISM-Intimate Shared Memory）
ISM使得共享內存被鎖在內存中，不能被換出（page out）。原本在一般情況下僅爲單獨進程創建的內存管理數據結構在一次性創建後就被所有進程共享。在Solaris 2.6操作環境下，還存在進一步的優化，內核試圖尋找可以作爲大的內存頁面被用來映射共享內存的連續的4-Mbyte物理內存塊。這大大降低了內存管理單元的開銷。（請看性能與調整——Java[tm]與Internet(Performance and Tuning - Java[tm] and the Internet)的333頁。）缺省情況下，類似Oracle、Informix、Sybase這樣的應用程序使用一個特殊的標誌來表明它們希望使用ISM。
ISM是一個關於虛擬內存實現方面，使得內核與硬件資源的使用更爲有效的很重要的優化。 並且，ISM提供了把頻繁用到的共享內存頁面鎖在內存中的方法。
在缺省情況下ISM是被允許的，不需要編輯/etc/system文件來打開這個特性。在具有當前補丁級別的內核上，關閉ISM會導致系統性能降級並且可能會掛起。而且在數據庫的配置文件中，比如Oracle的init.ora文件中，不應該有use_ism=false，因爲這樣會關閉ISM。
3.5. 與共享內存有關的交換空間設置
想要理解與共享內存有關的交換空間配置，請看Adrian Cockcroft寫的"清除在交換空間方面的混亂理解（Clearing Up Swap Space Confusion）"。
在設置交換空間大小的時候有兩個主要的考慮，就是要有足夠的：
內存，以避免在普通操作的時候就產生內存交換
交換空間，能夠放下一次崩潰記錄（crash dump）
3.6. 進程間通信（IPC）的參數
以下IPC參數值需要你的數據庫系統管理員（DBA）確定。Sun解決方案中心不能給出實際IPC參數設置應該是怎樣的建議。這些值依賴於應用程序。
在/etc/system的IPC參數設置中拼錯字是非常可能的。這種錯誤會對應用程序帶來嚴重的性能影響。要檢查拼寫錯誤，遍歷/var/adm/messages尋找這樣形式的消息：
genunix: [ID 492708 kern.notice] sorry, variable 'seminfo_semopn'
is not defined in the 'semsys'
這說明其中有一個拼寫錯誤。用Grep找"sorry"。
Solaris 8操作環境比以前的版本改進了IPC參數的缺省值。
對於Solaris 2.6操作環境之前的版本，共享內存需要更多的交換空間(也就是“後援空間”)。用swap -l，將block數值除2就可以得到兆字節數。應該有至少兩倍於已分配共享內存(shmmax)的交換空間。
這裏是shmmax的缺省值和最大值：
缺省 最大
shmmax 1048576 (Meg) 4294967295 (4GB) 2.5.1, 2.6, 32位solaris 7
2147483647 (2GB) 2.5或更低
在Solaris 2.6操作環境下，shmmax和shmmin是無符號整型(32位)。在Solaris 7操作環境下，"32位"的shmmax和shmmin是無符號整型(32位)。在Solaris 7操作環境下，"64位"的shmmax 和shmmin是無符號長整型(64位)。在所有情況下，shmmni和shmseg都是有符號整型(32位)。表2彙總了這些命令和它們的類型。
命令
Solaris 2.6
32位
Solaris 7
32位
Solaris 7
64位
shmmax
無符號整型
無符號整型
無符號長整型
shmmin
無符號整型
無符號整型
無符號長整型
shmmni
有符號整型
有符號整型
--
shmseg
有符號整型
有符號整型
--
表2: 命令類型
shmmax限值共享內存段的最大大小，這是shmget(2)所能請求的最大值。它所控制的資源不是預先分配的，而是根據需要分配的。
在Solaris 7和8環境下，64位突破了4-Gbyte的限制。這個最大值是理論上的。實際的設置需要根據象內存、數據庫大小、系統配置這些系統資源來確定。段的最大值本身(shmmax)是一個上限。
附加資源
A. 源自SunSolve Online[sm]關於IPC的文章
關於IPC參數話題，Sun解決方案中心已經寫了大量的文章。這些文章可以在SunSolve Online[sm]獲得。(合同客戶可以訪問附加的相關出版物。) 接下來是部分文章列表。
如果對/etc/system文件的修改似乎沒有起作用，請看文檔12824: sysdef -i 不報告設置在/etc/system中的IPC參數。
關於IPC參數的一般信息：
文檔6328: 在2.X中所有關於共享內存參數的信息
文檔2270: 理解信號燈、seminfo_信號燈信息
文檔12075: 如何在你的系統中配置IPC信號燈和共享內存
文檔5288: 如何通過adb確定IPC參數值
文檔2273: 針對消息隊列的內核調整參數
文檔7241: 確定消息隊列參數
關於調試問題：
文檔12174: 怎樣檢查系統使用了多少共享內存
文檔16985: 一個使用共享內存的進程已經終止，但是交換空間似乎沒有被回收
B. SUN性能信息
The Sun Performance page提供了各種資源。
SunWorld在線專欄 1995-1999
Cockcroft, Adrian和Richard Pettit, SUN性能與調整——Java[tm]與Internet（Sun Performance and Tuning - Java[tm] and the Internet）, Sun Microsystems Press, 1998. 這是一本有用的書，其中介紹的原則經受了時間的考驗。不過很多內容在應用到當前的系統時需要帶一點懷疑地去看待。
Garg, Rajat和Ilya Sharapov, 優化應用程序的技巧：高性能計算（Techniques for Optimizing Applications: High Performance Computing）, Sun BluePrints, 2001. 這本書是在基於Sun UltraSPARC技術的平臺上對計算密集型程序進行性能優化的實用指導，對於理解應用程序如何利用系統資源會有幫助。
Mauro, Jim和Richard McDougall, Solaris內部，核心內核架構（Solaris Internals, Core Kernel Architecture）, Sun Microsystems Press, 2001. 這本書被認爲是關於Solaris操作環境內部工作非常優秀的深入指南。
與性能和其他系統管理方面比如容量規劃有關的，源自Sun Blueprints[tm] Programs的大量出版物。
C. 相關文章和書籍
ITWorld.com上源自UnixInsider的文集: Jim Mauro已經寫了非常多介紹Solaris內核組件是如何工作的文章。如果你想知道“內幕”的話這是一個很好的起點。
Alomari, Ahmed, Oracle8i與UNIX性能調整（Oracle8i and UNIX Performance Tuning）, Prentice Hall PTR, 2001. (注: 1999年的早期版本針對的是Solaris 2.6操作環境。)
關於作者
Karen Edwards已經在Sun工作了七年。她最早的幾年是在加利福尼亞的SUN企業服務解決方案中心做外設與內核的支持。然後她爲SunSolve Online[sm] program工作，幫助提供內容以及給客戶做補丁問題的支持。目前她以作者身份爲Sun[sm] Alert program工作。看看SunSolv網站上新的Sun Alert Notification集合吧。
Clive King在SUN的客戶問題解決方案工程組工作。他擅長性能分析以及I/O子系統設備驅動方面的問題。作爲一個Kepner Tregoe認證的ATS（Analytic Trouble Shooting）課程講師，他在問題解決、決策制定和風險管理方面教授和實踐Rational過程。