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能够回答这个问题。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
