Solaris下的性能与调整

作者:C.Arthur 收藏
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过程。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/symield/archive/2005/02/06/283247.aspx