Solaris下的性能与调整.doc

1、Solaris 下的性能与调整ZT1. 着手性能问题 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）的参数 当一个系统运行缓慢性能下降的时候，很难知道原因是什么。是内存泄漏，磁盘子系统瓶颈，还是某个特定应用程序在可扩展性方面有限制？有一些途径可以发现和了解引起

2、性能问题的根源，并且有可能消除它。 本文给出了从哪里入手的一些建议。文中介绍了如何着手性能方面的考虑以及如何定位常见的性能瓶颈，还介绍了与性能密切相关一些概念，比如私有的共享内存（ISM-Intimate Shared Memory）与优先内存页面调度。文章重点是放在 Solaris 2.6, 7, 和 8 操作环境下。 1. 着手性能问题 性能，或许比计算机系统其它方面的行为更需要有通盘的考虑。为了识别来自一个或多个组件的问题根源，必须要采取结构化的方法。 实际的结果是，解决性能问题过程中最重要的一个部分是定义你正在试图解决的问题。从实际应用的方面来讲，这意味着定义一个操作或者测试用例，从而

3、可以： A) 知道系统当前有多快。 B) 知道系统需要快“X“倍；或者知道系统曾经在不同环境下快过“X“倍。 设置基线是开始的第一步。性能分析是由简单明确地定义所需解决的问题开始的自上而下的一个过程。如果你想要一个系统运行得快一些，你仍然需要定义这个系统的哪些属性是你想要改进的，以及哪些代价是你可以接受或者不可以接受的。除非你能够明确地描述出问题症状/机会，想要识别出问题的根源只会是碰运气。 性能分析很象是侦探工作，我们通过证据和观察建立事实依据，非常小心不要陷入预先想象的与事实不符的结论中只有在具备非常压倒性的证据时才确认猜想。 对所有假设都要怀疑。其他人声称的事实实际上只是个可能正确也可能

4、不正确的假设。如果这个假设是错误的，你可能会是在不正确的依据下工作，从而得出不正确的结论。 这里有一些警告。Solaris 操作环境在大多数情形下对于工作负荷的自我性能优化都是很好的。发行版本越新，需要手工做的性能优化就越少。性能问题的根源经常被发现是因为一个试图优化性能的行为引起的。首先需要注意应用程序，最后才是操作环境。 任何对系统配置的更改，比如象内存大小和磁盘布局这样的性能设置，都应该检查其当前的正确性。同样，一个带参数的系统升级也有可能对新操作环境的性能带来影响。 2. 性能监测 2.1. 从暴露出来的问题开始 什么操作使你看到性能问题的症状？ 比如说，是特定类型的数据库查询，文件或

5、网络操作比你期望的慢？在给出测试用例方面你能把操作步骤做到多具体，例如一个 SQL 查询或者 30 行的 C 程序？ 最大程度利用你的知识尽可能准确地说明“什么地方出了什么问题”以定义你的问题。良好的问题说明的例子就像这样： 一个 SQL 查询在 VXFS 上比在 UFS 上要花两倍的时间。 SVR4 消息队列操作在操作环境版本 A 上比在操作环境版本 B 上要多花百分之 30的时间。 登录进系统 A 比登录进系统 Y 多花三倍的时间。 一个问题说明不应该包括解决方法或者是可能的解决方法。 在大部分的时候，对问题有一个清晰的说明就意味着完成了解决问题过程的一大半了。在对你试图解决的问题进行说明

6、的时候考虑到用户观点的因素也很重要，这意味着要从应用程序的角度来看。这和人们的天性相反，人们总是通过实验试图去证明或者证伪一个可能的原因，而不是依据观察得到的事实来评估一个原因的可能性程度。 不恰当的问题说明就象这样： mpstat 的“wt“列表明等待时间过多。 用户任务花时间太长。 一个系统和它的应用程序的功能正确性问题与性能问题之间的边界往往是一个灰色地带。整个系统挂起与进程挂起的问题不在本文讨论范围之内。如果你怀疑系统的功能不正确，而不是性能问题，那么给你的 SUN 解决方案中心打电话以找到一个解决问题的方法。高性能系统的前提是它的功能首先要正确。 作为你积极的维护计划的一部分，检查/

7、var/adm/messages 中有没有比如磁盘重试之类的硬件问题或者有没有额外的消息产生也是很有价值的。 察看系统的历史信息也非常有价值；如果你的系统曾经有过更好的性能，画一条时间曲线详细记录何时第一次发现性能变差以及从什么时候开始性能一直很差。 2.2. 知道你的系统在正常情况下会怎样 保存你的系统是如何正常运转的样例是一个好主意。你可以很容易地收集和保存每月的性能数据，比如： *stat 类：vmstat, mpstat, iostat, vxstat sar ps 的输出以显示哪些进程在运行 (在 Solaris 8 操作环境下是 prstat) 另外，有不少商业的和无支持的产品都可

8、以用来做性能监测。一个免费的无支持的可选产品是 SE Toolkit（要获得其各种版本的信息，请看 Sun Performance SE Toolkit page）。SE Toolkit 报告磁盘活动、CPU 利用情况、TCP 和网络连接、内存，以及其他更多信息。在我们的经验里，它安装方便，不需要重启系统，并且生成容易理解的图形显示。 很多这类产品都存在一个共同的问题，就是对不同的硬件配置有不同的门限值。例如，特定的门限值对于 400-MHz 的系统可能显得太过，会让这个系统慢得象是在爬一样，但是对于一个 900-MHz 的系统却可能是可以接受的。 2.3. 寻找性能瓶颈 一旦你已经定义了需要

9、解决的性能问题，下一步骤就是缩小范围到瓶颈产生的地方。 这个阶段有必要问这样一些问题： 应用程序能告诉我它看到哪些是瓶颈？拿 Oracle 作例子，一个 Oracle 数据库管理员应该知道 BSTAT/ESTATS 是什么以及如何运行和理解它们。还是那句话，从应用程序的角度来看问题，BSTATS/ESTATS 可以显示限制了 Oralce 性能的瓶颈，这可以作为进一步分析的指导。 大部分的时间花在哪里，是内核还是用户进程？通过 vmstat、mpstat、sar、ps、prstat 可以回答这个问题。 具有相近类型的所有资源是否同样繁忙？这个问题的意义在于寻找资源的不平等分布。比如，一个磁盘可

10、能是瓶颈所在，或者一个 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 的输出结果非常有用。

11、我们现在来看看怎用使用一些常见的 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 5

12、8 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

13、 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 空闲时间。这台

14、机器没有足够的 CPU 资源以满足进程运行的需要，这可以从它的大部分 CPU 时间花在用户空间里看出来(看“us“列)。 这里有两种办法可供采用第一，增加更多的 CPU，或者第二，对应用程序的代码作性能分析看看是不是应用程序的某部分可以优化。对代码片断作优化可能会需要非常大量的努力而且有时候收到的效果很少。在关系到时间的时候，最好在考虑你可能的“投资回报”时现实一点。 2.3.2. mpstat -使用 mpstat 命令 mpstat 命令报告每个处理器的统计信息，表格中的每一行代表一个处理器的活动情况。 $ mpstat 5 CPU minf mjf xcal intr ithr csw

15、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 s

16、rw 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

17、 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 都在花时间做什么：比如，分配给系统、用户、等待、空闲时间、系统调用、锁竞争、中断、错误、交叉调用。 有关每一列的详细含义请看

18、 mpstat(1M)的手册页。 2.3.3. iostat -使用 iostat 命令 iostat 命令报告磁盘的使用情况。表格中的每一行代表一个磁盘的活动信息。常用的选项有这些： 选项 说明 N 按 cXtYdZ 格式指定磁盘。 X 报告扩展统计信息。 z 这个选项在 Solaris 8 操作环境中是新的。它使得在采样间隔中没有磁盘活动的那些行被省略掉，这样可以让输出简短一些并且突出那些有活动的磁盘。 p 和 P 报告分区前（per-partition）的 I/O 统计信息，当察看内存交换设备的时候有用。 E 对于找出产生错误的磁盘有用。 表 1：iostat 的选项 iostat 也可

19、以透过 NFS 报告磁盘活动，不过可能产生比较长的报告。 2.3.4. truss -你的朋友 truss(1M)工具执行制定的命令并且生成一个追踪记录，包括它执行的系统调用、接收到的信号、导致的机器错误（traps/interruptions译者注）。 truss 也可以用来追踪一个正在退出的进程。这是一个非常有用的工具，可以定位应用程序向内核请求了哪些变慢了或者是被过度使用的资源。 如果你不了解 truss，那么可以看看手册页并且试一试。-m 选项对于显示例如页面错误这样的错误非常有用。-c 选项可以给出这样一个汇总信息： 系统调用 错误 信号 在每一类型系统调用上累计的时间 失败的系统调

20、用数目 2.3.5. lockstat -资源竞争 内核锁可以保护对数据结构的多重更新，并且控制对诸如磁盘缓存、网络缓存、各种内核缓存这些资源的访问。 lockstat 执行一个命令，报告在命令执行期间所有内核锁的活动情况，不论请求锁的是哪个进程或设备。请看 lockstat(1M)的手册页。-s 10 选项报告在每一个锁上进行竞争的内核线程栈。 2.3.6. trapstat -运行时的陷阱统计 trapstat 是一个在运行着普通 Solaris 内核的 UltraSPARC?处理器上提供运行时陷阱（trap）统计信息的工具。对于 I-TLB 和 D-TLB 未命中，trapstat 能够

21、可选地显示花在操作系统 TLB 未命中处理程序中的时间量。对于中断向量陷阱，trapstat 能够可选地显示中断设备。 2.3.7. gprof -应用程序性能分析 对于 C、C+和 FORTRAN 应用，试试用-xpg 选项编译，并且在会产生性能问题的典型负载下运行这个程序。对生成的 tmon.out 文件执行 gprof。这可以显示出该应用程序大部分的时间花在哪里。 Fortetm TeamWare (以前的 Sun WorkShoptm TeamWare) 有很多有用的工具，比如用图形化的方式表示应用程序的时间都花在哪里的分析工具。要想了解更进一步的信息，请看 Forte TeamWar

22、e 文档以及 Rajat Garg 与 Ilya Sharapov 的 Suntm BluePrints 书籍，应用程序的优化技巧：高性能计算（Techniques for Optimizing Applications: High Performance Computing）. 2.3.8. proc 工具 proc 是一个利用/proc 的特性来报告比如这样一些进程属性的实用工具： pstack -调用栈 ptree -进程关系树 pfiles -打开的文件描述符列表 pldd -正在运行中的进程使用的动态链接库的列表 更多信息请看 proc(1)的手册页。 3. 一些常见问题和一些建议

23、3.1. 64 位的运算与容量能带来什么？ 从性能的角度看，可以运行 64 位应用程序的能力有两大好处。首先是更大规模的问题能够利用更大的进程地址空间获得有效解决。其次是整数运算可以使用64 位的寄存器和指令。 整体来说，因为代码中的指针和数据结构都更大了所以程序也稍微变大一些。反过来，这意味着 CPU 的缓存也很有可能没有足够的缓存行，那些在 32 位环境下就能够运行得很好的程序可能会稍微有一点慢。 内核线程栈是 16Kb 而不是 8Kb，不过产生的效果经常是可以忽略的。 3.2. 空闲内存 检查一个 Solaris 系统以确定还有多少空闲内存一直以来都是个容易引起混淆的地方。 对于 Sol

24、aris 8 操作环境之前的版本，要想察看是否内存不够，是不依赖于“free“列或者“sr“列的。在“fr“列中的值并不能指示内存缺乏。页面缓存一直保留住页面以备再次需要用到它们。虚拟内存子系统只在需要的时候才收回内存。 在 SunWorld 文章与 SUN 性能与调整Javatm与 Internet（Sun Performance and Tuning - Javatm and the Internet）中这个题目已经被写了很多了。为了确定是否有内存不足的情况存在，同时检查第 12 列(“sr“，也就是扫描率)和交换分区的磁盘 I/O 流量(用 iostat -P)。如果大量的 I/O 活动

25、由文件系统产生并且需要运行页面扫描程序为 I/O 释放页面，“sr“列会有比较大的数值。 只有在空闲链表缩短到一个门限值 (lotsfree，以页面为单位)以下，pageout扫描程序才运行。任何非活动的并且没有被锁在内存中的进程或文件页面都可能被换出。freelist 的大小看上去会缩短并保持在那个数值(lotsfree)。当 freelist 的数量下降到 lotsfree 门限以下的时候，页面守护进程将启动，扫描需要从页面缓存以及已退出和空闲的进程中回收的内存。没有办法能够让“空闲“值增长到这个门限以上很多，因为没有办法让页面扫描程序在这个门限之外回收内存。让页面保留在页面缓存中比把它们

26、不必要地放到空闲链表中更有效率。 Solaris 8 操作环境在 segmap 驱动程序内实现了一个更为有效的算法给 I/O 提供所需的页面。vmstat 中的“fr“列确实反映了空闲并且没有被页面缓存所使用的内存。-p 选项被加到 vmstat 中，用来给出更准确的页面调度行为细节。 对于单独的进程，pmap 命令报告单独进程的内存空间布局情况(-x 选项比较有用)。 3.3. 优先内存页面调度 优先内存页面调度是在 Solaris 7 操作环境引入的，并被向后移植到了 Solaris 2.6 操作环境(内核补丁 105181-XX)和 Solaris 2.5.1 操作环境(内核补丁 103

27、640-XX)。这两个补丁的最近版本可以在 SunSolve Onlinesm找到。 优先内存页面调度提供了一种改进的页面调度算法，从而在文件系统被使用的时候可以明显地改善系统的响应速度。优先内存页面调度引入了一个新增加的名词，cachefree。页面调度参数现在有这些： minfree desfree lotsfree cachefree 缺省情况下这个新功能在 Solaris 2.5.1, 2.6, 和 7 操作环境下是关闭的，所以在有明显频繁内存调度的系统上允许这个功能就很重要。当 priority_paging 没有被允许的时候，cachefree 被置为与 lotsfree 一样。当

28、它被允许的时候，缺省情况下 cachefree 被设置为 lotsfree 的 2 倍。 调整这个参数趋于使工作站系统上窗口间切换起来更快，这对于需要从文件系统中把大文件读入内存的运行数据库的系统是很大的帮助。在通过文件系统执行大量 I/O 操作的系统上，对于拥有大量数据集的计算密集型任务，百分之几百的速度提高都曾经有过。 Solaris 8 操作环境采用了一种不同的算法，消除了以前版本中页面扫描程序必须扫描内存以供给 segmap 驱动程序来存放 I/O 的限制因素。segmap 不再需要的所有内存页面都被放到一个可以立即重用的链表中。不要在 Solaris 8 操作环境中设置 priori

29、ty_paging。并且，Solaris 8 操作环境应该不需要手工调整虚拟内存参数，除了在大系统中把 fastscan 和 maxpgio 设置到高一些的值会有益。 更多关于优先内存页面调度的信息，请参考下面这些： Sun 性能、优先内存页面调度 FAQ 文档 17946: 在 2.5.1+中针对优先内存页面调度的新的内核可调整项 3.4. 隐私的共享内存（ISM-Intimate Shared Memory） ISM 使得共享内存被锁在内存中，不能被换出（page out）。原本在一般情况下仅为单独进程创建的内存管理数据结构在一次性创建后就被所有进程共享。在 Solaris 2.6 操作环

30、境下，还存在进一步的优化，内核试图寻找可以作为大的内存页面被用来映射共享内存的连续的 4-Mbyte 物理内存块。这大大降低了内存管理单元的开销。（请看性能与调整Javatm与 Internet(Performance and Tuning - Javatm and the Internet)的 333 页。）缺省情况下，类似 Oracle、Informix、Sybase 这样的应用程序使用一个特殊的标志来表明它们希望使用 ISM。 ISM 是一个关于虚拟内存实现方面，使得内核与硬件资源的使用更为有效的很重要的优化。 并且，ISM 提供了把频繁用到的共享内存页面锁在内存中的方法。 在缺省情况下

31、 ISM 是被允许的，不需要编辑/etc/system 文件来打开这个特性。在具有当前补丁级别的内核上，关闭 ISM 会导致系统性能降级并且可能会挂起。而且在数据库的配置文件中，比如 Oracle 的 init.ora 文件中，不应该有use_ism=false，因为这样会关闭 ISM。 3.5. 与共享内存有关的交换空间设置 想要理解与共享内存有关的交换空间配置，请看 Adrian Cockcroft 写的“清除在交换空间方面的混乱理解（Clearing Up Swap Space Confusion）“。 在设置交换空间大小的时候有两个主要的考虑，就是要有足够的： 内存，以避免在普通操作的

32、时候就产生内存交换 交换空间，能够放下一次崩溃记录（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 defin

33、ed 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

34、(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 无符号整型 无符号整型 无

35、符号长整型 shmmin 无符号整型 无符号整型 无符号长整型 shmmni 有符号整型 有符号整型 - shmseg 有符号整型 有符号整型 - 表 2: 命令类型 shmmax 限值共享内存段的最大大小，这是 shmget(2)所能请求的最大值。它所控制的资源不是预先分配的，而是根据需要分配的。 在 Solaris 7 和 8 环境下，64 位突破了 4-Gbyte 的限制。这个最大值是理论上的。实际的设置需要根据象内存、数据库大小、系统配置这些系统资源来确定。段的最大值本身(shmmax)是一个上限。 附加资源 A. 源自 SunSolve Onlinesm关于 IPC 的文章 关于 I

36、PC 参数话题，Sun 解决方案中心已经写了大量的文章。这些文章可以在 SunSolve Onlinesm获得。(合同客户可以访问附加的相关出版物。) 接下来是部分文章列表。 如果对/etc/system 文件的修改似乎没有起作用，请看文档 12824: sysdef -i 不报告设置在/etc/system 中的 IPC 参数。 关于 IPC 参数的一般信息： 文档 6328: 在 2.X 中所有关于共享内存参数的信息 文档 2270: 理解信号灯、seminfo_信号灯信息 文档 12075: 如何在你的系统中配置 IPC 信号灯和共享内存 文档 5288: 如何通过 adb 确定 IPC

37、 参数值 文档 2273: 针对消息队列的内核调整参数 文档 7241: 确定消息队列参数 关于调试问题： 文档 12174: 怎样检查系统使用了多少共享内存 文档 16985: 一个使用共享内存的进程已经终止，但是交换空间似乎没有被回收 B. SUN 性能信息 The Sun Performance page 提供了各种资源。 SunWorld 在线专栏 1995-1999 Cockcroft, Adrian 和 Richard Pettit, SUN 性能与调整Javatm与 Internet（Sun Performance and Tuning - Javatm and the Inte

38、rnet）, Sun Microsystems Press, 1998. 这是一本有用的书，其中介绍的原则经受了时间的考验。不过很多内容在应用到当前的系统时需要带一点怀疑地去看待。 Garg, Rajat 和 Ilya Sharapov, 优化应用程序的技巧：高性能计算（Techniques for Optimizing Applications: High Performance Computing）, Sun BluePrints, 2001. 这本书是在基于 Sun UltraSPARC 技术的平台上对计算密集型程序进行性能优化的实用指导，对于理解应用程序如何利用系统资源会有帮助。 Ma

39、uro, Jim 和 Richard McDougall, Solaris 内部，核心内核架构（Solaris Internals, Core Kernel Architecture）, Sun Microsystems Press, 2001. 这本书被认为是关于 Solaris 操作环境内部工作非常优秀的深入指南。 与性能和其他系统管理方面比如容量规划有关的，源自 Sun Blueprintstm Programs 的大量出版物。 C. 相关文章和书籍 ITW 上源自 UnixInsider 的文集: Jim Mauro 已经写了非常多介绍 Solaris 内核组件是如何工作的文章。如果你

40、想知道“内幕”的话这是一个很好的起点。 Alomari, Ahmed, Oracle8i 与 UNIX 性能调整（Oracle8i and UNIX Performance Tuning）, Prentice Hall PTR, 2001. (注: 1999 年的早期版本针对的是 Solaris 2.6 操作环境。) 关于作者 Karen Edwards 已经在 Sun 工作了七年。她最早的几年是在加利福尼亚的 SUN企业服务解决方案中心做外设与内核的支持。然后她为 SunSolve Onlinesm program 工作，帮助提供内容以及给客户做补丁问题的支持。目前她以作者身份为 Sunsm Alert program 工作。看看 SunSolv 网站上新的 Sun Alert Notification 集合吧。 Clive King 在 SUN 的客户问题解决方案工程组工作。他擅长性能分析以及 I/O子系统设备驱动方面的问题。作为一个 Kepner Tregoe 认证的 ATS（Analytic Trouble Shooting）课程讲师，他在问题解决、决策制定和风险管理方面教授和实践 Rational 过程。