Solaris下的性能与调整.doc

Solaris下的性能与调整ZT1.着手性能问题 2.性能监测 2.1.从暴露出来的问题开始 2.2.知道你的系统在正常情况下会怎样 2.3.寻找性能瓶颈 3.一些常见问题和一些建议 3.1.64位的运算与容量能带来什么 3.2.空闲内存 3.3.优先内存页面调度 3.4.隐私的共享内存（ISM-IntimateSharedMemory） 3.5.与共享内存有关的交换空间设置 3.6.进程间通信（IPC）的参数 当一个系统运行缓慢性能下降的时候，很难知道原因是什么。是内存泄漏，磁盘子系统瓶颈，还是某个特定应用程序在可扩展性方面有限制？有一些途径可以发现和了解引起性能问题的根源，并且有可能消除它。 本文给出了从哪里入手的一些建议。文中介绍了如何着手性能方面的考虑以及如何定位常见的性能瓶颈，还介绍了与性能密切相关一些概念，比如私有的共享内存（ISM-IntimateSharedMemory）与优先内存页面调度。文章重点是放在Solaris2.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的输出以显示哪些进程在运行(在Solaris8操作环境下是prstat) 另外，有不少商业的和无支持的产品都可以用来做性能监测。一个免费的无支持的可选产品是SEToolkit（要获得其各种版本的信息，请看SunPerformanceSEToolkitpage）。SEToolkit报告磁盘活动、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-eopid,pcpu,args|sort+1n CPU百分比 ps-eopid,vsz,args|sort+1n K字节的虚拟内存 /usr/ucb/psaux|more 输出被排序，使用CPU和内存最多的进程排在上面。 Solaris8操作环境提供了prstat，它给出CPU和内存使用情况的一个动态注解。prstat-cvm的输出结果非常有用。 我们现在来看看怎用使用一些常见的Solaris命令来开始性能分析。 2.3.1.vmstat-使用vmstat命令 vmstat命令是简单的。这里我们可以看到一个对于正在执行的应用程序，CPU能力不足的例子。 %vmstat15 procsmemorypagediskfaultscpu rbwswapfreeremfpipofrdesrm0m1m2m3insycsussyid 450028872161821043707449645508026101531579798361309 580028313124640859835825632110492000014134797102769310 550028309445606426496563806012100001441462798969310 5700282770448760481872368000121001016064316116066340 560028247124751268576045617360261001015844939108668320 580028134004705678566733323740355000016765112111470300 6010281671249464786172067310110703023296131106764360 5800281755248392458552109960146000013576724105971290 vmstat输出的第一行总是可以忽略。在procs下面标着r的一列是等待获得CPU的进程运行队列中的进程数。id列是CPU空闲时间。这台机器没有足够的CPU资源以满足进程运行的需要，这可以从它的大部分CPU时间花在用户空间里看出来(看us列)。 这里有两种办法可供采用第一，增加更多的CPU，或者第二，对应用程序的代码作性能分析看看是不是应用程序的某部分可以优化。对代码片断作优化可能会需要非常大量的努力而且有时候收到的效果很少。在关系到时间的时候，最好在考虑你可能的“投资回报”时现实一点。 2.3.2.mpstat-使用mpstat命令 mpstat命令报告每个处理器的统计信息，表格中的每一行代表一个处理器的活动情况。 $mpstat5 CPUminfmjfxcalintrithrcswicswmigrsmtxsrwsysclusrsyswtidl 02003592335023381355431842850457896184 119030446528321391353981400617096185 2250352507295215315843318307508127181 3260357513302208215542518107460127081 CPUminfmjfxcalintrithrcswicswmigrsmtxsrwsysclusrsyswtidl 03038793773275418326132233903424127081 120555544264304019767011204828156078 2110188595269314121973812105291186175 3650185585279266021167311005420229069 CPUminfmjfxcalintrithrcswicswmigrsmtxsrwsysclusrsyswtidl 06040283633262016955128734302857128080 170150545265304419666311704374144081 2140226602279282322570710304715224173 320125600282281023069911804665184078 mpstat可以确定每一个CPU都在花时间做什么：比如，分配给系统、用户、等待、空闲时间、系统调用、锁竞争、中断、错误、交叉调用。 有关每一列的详细含义请看mpstat(1M)的手册页。 2.3.3.iostat-使用iostat命令 iostat命令报告磁盘的使用情况。表格中的每一行代表一个磁盘的活动信息。常用的选项有这些： 选项 说明 N 按cXtYdZ格式指定磁盘。 X 报告扩展统计信息。 z 这个选项在Solaris8操作环境中是新的。它使得在采样间隔中没有磁盘活动的那些行被省略掉，这样可以让输出简短一些并且突出那些有活动的磁盘。 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)的手册页。-s10选项报告在每一个锁上进行竞争的内核线程栈。 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。这可以显示出该应用程序大部分的时间花在哪里。 FortetmTeamWare(以前的SunWorkShoptmTeamWare)有很多有用的工具，比如用图形化的方式表示应用程序的时间都花在哪里的分析工具。要想了解更进一步的信息，请看ForteTeamWare文档以及RajatGarg与IlyaSharapov的SuntmBluePrints书籍，应用程序的优化技巧：高性能计算（TechniquesforOptimizingApplications:HighPerformanceComputing）. 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系统以确定还有多少空闲内存一直以来都是个容易引起混淆的地方。 对于Solaris8操作环境之前的版本，要想察看是否内存不够，是不依赖于free列或者sr列的。在fr列中的值并不能指示内存缺乏。页面缓存一直保留住页面以备再次需要用到它们。虚拟内存子系统只在需要的时候才收回内存。 在SunWorld文章与SUN性能与调整Javatm与Internet（SunPerformanceandTuning-JavatmandtheInternet）中这个题目已经被写了很多了。为了确定是否有内存不足的情况存在，同时检查第12列(sr，也就是扫描率)和交换分区的磁盘I/O流量(用iostat-P)。如果大量的I/O活动由文件系统产生并且需要运行页面扫描程序为I/O释放页面，sr列会有比较大的数值。 只有在空闲链表缩短到一个门限值(lotsfree，以页面为单位)以下，pageout扫描程序才运行。任何非活动的并且没有被锁在内存中的进程或文件页面都可能被换出。freelist的大小看上去会缩短并保持在那个数值(lotsfree)。当freelist的数量下降到lotsfree门限以下的时候，页面守护进程将启动，扫描需要从页面缓存以及已退出和空闲的进程中回收的内存。没有办法能够让空闲值增长到这个门限以上很多，因为没有办法让页面扫描程序在这个门限之外回收内存。让页面保留在页面缓存中比把它们不必要地放到空闲链表中更有效率。 Solaris8操作环境在segmap驱动程序内实现了一个更为有效的算法给I/O提供所需的页面。vmstat中的fr列确实反映了空闲并且没有被页面缓存所使用的内存。-p选项被加到vmstat中，用来给出更准确的页面调度行为细节。 对于单独的进程，pmap命令报告单独进程的内存空间布局情况(-x选项比较有用)。 3.3.优先内存页面调度 优先内存页面调度是在Solaris7操作环境引入的，并被向后移植到了Solaris2.6操作环境(内核补丁105181-XX)和Solaris2.5.1操作环境(内核补丁103640-XX)。这两个补丁的最近版本可以在SunSolveOnlinesm找到。 优先内存页面调度提供了一种改进的页面调度算法，从而在文件系统被使用的时候可以明显地改善系统的响应速度。优先内存页面调度引入了一个新增加的名词，cachefree。页面调度参数现在有这些： minfreedesfreelotsfreecachefree 缺省情况下这个新功能在Solaris2.5.1,2.6,和7操作环境下是关闭的，所以在有明显频繁内存调度的系统上允许这个功能就很重要。当priority_paging没有被允许的时候，cachefree被置为与lotsfree一样。当它被允许的时候，缺省情况下cachefree被设置为lotsfree的2倍。 调整这个参数趋于使工作站系统上窗口间切换起来更快，这对于需要从文件系统中把大文件读入内存的运行数据库的系统是很大的帮助。在通过文件系统执行大量I/O操作的系统上，对于拥有大量数据集的计算密集型任务，百分之几百的速度提高都曾经有过。 Solaris8操作环境采用了一种不同的算法，消除了以前版本中页面扫描程序必须扫描内存以供给segmap驱动程序来存放I/O的限制因素。segmap不再需要的所有内存页面都被放到一个可以立即重用的链表中。不要在Solaris8操作环境中设置priority_paging。并且，Solaris8操作环境应该不需要手工调整虚拟内存参数，除了在大系统中把fastscan和maxpgio设置到高一些的值会有益。 更多关于优先内存页面调度的信息，请参考下面这些： Sun性能、优先内存页面调度FAQ 文档17946:在2.5.1+中针对优先内存页面调度的新的内核可调整项 3.4.隐私的共享内存（ISM-IntimateSharedMemory） ISM使得共享内存被锁在内存中，不能被换出（pageout）。原本在一般情况下仅为单独进程创建的内存管理数据结构在一次性创建后就被所有进程共享。在Solaris2.6操作环境下，还存在进一步的优化，内核试图寻找可以作为大的内存页面被用来映射共享内存的连续的4-Mbyte物理内存块。这大大降低了内存管理单元的开销。（请看性能与调整Javatm与Internet(PerformanceandTuning-JavatmandtheInternet)的333页。）缺省情况下，类似Oracle、Informix、Sybase这样的应用程序使用一个特殊的标志来表明它们希望使用ISM。 ISM是一个关于虚拟内存实现方面，使得内核与硬件资源的使用更为有效的很重要的优化。并且，ISM提供了把频繁用到的共享内存页面锁在内存中的方法。 在缺省情况下ISM是被允许的，不需要编辑/etc/system文件来打开这个特性。在具有当前补丁级别的内核上，关闭ISM会导致系统性能降级并且可能会挂起。而且在数据库的配置文件中，比如Oracle的init.ora文件中，不应该有use_ism=false，因为这样会关闭ISM。 3.5.与共享内存有关的交换空间设置 想要理解与共享内存有关的交换空间配置，请看AdrianCockcroft写的清除在交换空间方面的混乱理解（ClearingUpSwapSpaceConfusion）。 在设置交换空间大小的时候有两个主要的考虑，就是要有足够的： 内存，以避免在普通操作的时候就产生内存交换 交换空间，能够放下一次崩溃记录（crashdump） 3.6.进程间通信（IPC）的参数 以下IPC参数值需要你的数据库系统管理员（DBA）确定。Sun解决方案中心不能给出实际IPC参数设置应该是怎样的建议。这些值依赖于应用程序。 在/etc/system的IPC参数设置中拼错字是非常可能的。这种错误会对应用程序带来严重的性能影响。要检查拼写错误，遍历/var/adm/messages寻找这样形式的消息： genunix:ID492708kern.noticesorry,variableseminfo_semopn isnotdefinedinthesemsys 这说明其中有一个拼写错误。用Grep找sorry。 Solaris8操作环境比以前的版本改进了IPC参数的缺省值。 对于Solaris2.6操作环境之前的版本，共享内存需要更多的交换空间(也就是“后援空间”)。用swap-l，将block数值除2就可以得到兆字节数。应该有至少两倍于已分配共享内存(shmmax)的交换空间。 这里是shmmax的缺省值和最大值： 缺省最大 shmmax1048576(Meg)4294967295(4GB)2.5.1,2.6,32位solaris7 2147483647(2GB)2.5或更低 在Solaris2.6操作环境下，shmmax和shmmin是无符号整型(32位)。在Solaris7操作环境下，32位的shmmax和shmmin是无符号整型(32位)。在Solaris7操作环境下，64位的shmmax和shmmin是无符号长整型(64位)。在所有情况下，shmmni和shmseg都是有符号整型(32位)。表2汇总了这些命令和它们的类型。 命令 Solaris2.6 32位 Solaris7 32位 Solaris7 64位 shmmax 无符号整型 无符号整型 无符号长整型 shmmin 无符号整型 无符号整型 无符号长整型 shmmni 有符号整型 有符号整型 - shmseg 有符号整型 有符号整型 - 表2:命令类型 shmmax限值共享内存段的最大大小，这是shmget(2)所能请求的最大值。它所控制的资源不是预先分配的，而是根据需要分配的。 在Solaris7和8环境下，64位突破了4-Gbyte的限制。这个最大值是理论上的。实际的设置需要根据象内存、数据库大小、系统配置这些系统资源来确定。段的最大值本身(shmmax)是一个上限。 附加资源 A.源自SunSolveOnlinesm关于IPC的文章 关于IPC参数话题，Sun解决方案中心已经写了大量的文章。这些文章可以在SunSolveOnlinesm获得。(合同客户可以访问附加的相关出版物。)接下来是部分文章列表。 如果对/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性能信息 TheSunPerformancepage提供了各种资源。 SunWorld在线专栏1995-1999 Cockcr