Solaris下的性能与调整

《Solaris下的性能与调整》由会员分享，可在线阅读，更多相关《Solaris下的性能与调整（13页珍藏版）》请在金锄头文库上搜索。

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 的输出以显示哪些进程在运行 (在 S

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

9、于一个 900-MHz 的系统却可能是可以接受的。 2.3. 寻找性能瓶颈 一旦你已经定义了需要解决的性能问题，下一步骤就是缩小范围到瓶颈产生的 地方。 这个阶段有必要问这样一些问题： 应用程序能告诉我它看到哪些是瓶颈？拿 Oracle 作例子，一个 Oracle 数据库 管理员应该知道 BSTAT/ESTATS 是什么以及如何运行和理解它们。还是那句话， 从应用程序的角度来看问题，BSTATS/ESTATS 可以显示限制了 Oralce 性能的瓶 颈，这可以作为进一步分析的指导。 大部分的时间花在哪里，是内核还是用户进程？通过 vmstat、mpstat、sar、p s、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 操作环境提

11、供了 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 1

12、82104 3 707 449 6 455 0 80 2 6 1 0 1531 5797 983 61 3 0 9 58 0 0 2831312 46408 5 983 582 56 3211 0 492 0 0 0 0 1413 4797 1027 6 9 31 0 55 0 0 2830944 56064 2 649 656 3 806 0 121 0 0 0 0 1441 4627 989 69 3 1 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 47

13、512 6 857 604 56 1736 0 261 0 0 1 0 1584 4939 1086 6 8 32 0 58 0 0 2813400 47056 7 856 673 33 2374 0 355 0 0 0 0 1676 5112 1114 7 0 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 输出的第一行总是

14、可以忽略。在“procs“下面标着“r“的一列是等待获得 CPU 的进程运行队列中的进程数。“id“列是 CPU 空闲时间。这台机器没有足够 的 CPU 资源以满足进程运行的需要，这可以从它的大部分 CPU 时间花在用户空 间里看出来(看“us“列)。 这里有两种办法可供采用第一，增加更多的 CPU，或者第二，对应用程序 的代码作性能分析看看是不是应用程序的某部分可以优化。对代码片断作优化 可能会需要非常大量的努力而且有时候收到的效果很少。在关系到时间的 时候，最好在考虑你可能的“投资回报”时现实一点。 2.3.2. mpstat -使用 mpstat 命令 mpstat 命令报告每个处理器的

15、统计信息，表格中的每一行代表一个处理器的活 动情况。 $ mpstat 5 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt i dl 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 42

16、5 181 0 7460 12 7 0 81 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt i dl 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