Unix环境性能监控.pdf

引言 几个注意事项 监控CPU性能数据 监控内存性能数据 监控磁盘IO性能数据 监控网络性能数据 收集服务器性能数据 小结 附：获取solaris10系统信息  引言  本文是基于unix平台（以solaris为例，其他系统会有少许差异） 讲解如何监控服务器的性能、如何获取服务器的性能数 据作为解决项目性能瓶颈和性能调优的依据。文档中会 按序讲解CPU、Memory、I/O、Network四个部分， 并穿插讲解一些命令/工具的使用，同时也会给出一些性 能数据的“参考值”作为借鉴，希望能够解决大家对服 务器性能数据的一些疑惑，并给大家的日常工作提供帮 助。 引言 几个注意事项 监控CPU性能数据 监控内存性能数据 监控磁盘IO性能数据 监控网络性能数据 收集服务器性能数据 小结 附：获取solaris10系统信息  什么是瓶颈？举出几 个性能瓶颈的例子。  你所理解性能调优是 什么？  虽然讲解过程中是顺序的、单独的讲解如何监控/采集每 项系统资源的性能数据，但是一定要清楚“服务器各类 资源之间的关系是相互依赖、相互制约的”不要孤立的 看待某一项性能数据趋于正常/出现瓶颈就妄下结论  例1：用top查看某系统的idle(cpu空闲)95%，并不能说明系统没 有性能问题，很可能是因为系统在忙于处理磁盘I/O。  例2：某系统的的性能问题表现为CPU利用率高，其实可能是内存 不够用导致CPU消耗在内存管理上，如果用增加CPU方法来优化是 解决不了根本问题的。  例3：某系统网络数据传输指标不理想，于是调高了网络吞吐量使 监控到网络数据趋于正常，但却带来了新的问题“系统因为增加 网络吞吐量而导致CPU出现了瓶颈。”  讲解过程/网上资料中会给出一些“参考值”，顾名思义 仅仅能提供给你做对比的参考，不要用来作为“标准”， 这些参考值都有一个适用的环境，需要根据项目、应用、 系统类型适当的调整这些标准。  例1：Oracle等数据库生来就是I/O大户,用一般应用服务器的标准 来衡量oracle数据库服务器的性能是不恰当的。  例2：我们的web应用高并发的情况下则会占用更多的CPU资源。  例3：一个高性能的服务器存在超出“标准”的CS （上下文切换） 也是正常的。  分析性能问题时需要有“天马行空”的思维（指的是广阔思维、合理的 猜想，而不是胡思乱想），敢于假设、敢于猜想：“我感觉这个问题出 在磁盘I/O上…；瓶颈有可能是网络带宽…”但是对待监控/采集性 能数据要杜绝猜想，要有非常严谨的态度，要用数据和事实来说话。  专业的的性能测试人员要用实际的数据说话，不要讲“性能感觉比较 差了”或者是“系统响应比较慢了”一类的话。系统响应比较慢，要 知道正常是多少、慢了多少、数据量有多少、系统有多少并发等，拿 出具体的数据。  杜绝主观的臆想或臆造性能数据，在不正确的依据下工作，将直接导 致性能调优的结果出现偏离 引言 几个注意事项 监控CPU性能数据 监控内存性能数据 监控磁盘IO性能数据 监控网络性能数据 收集服务器性能数据 小结 附：获取solaris10系统信息  运行队列 运行队列/cpu数目*100%=cpu饱和度  CPU使用率 用户使用率+系统使用率=cpu利用率  上下文切换context switching （CS） 单CPU的分身术（假象）  System Activity Reporter （系统活跃情况报告）的缩写  监控系统资源的常用命令之一，多用于监控CPU和内存  sar是一个低开销的系统性能监控/采集工具  sar可以连续对系统采样  采样数据可以存储在文件中，便于查询历史数据  sar 命令格式：sar [options] [-A] [-o file] t [n]  t为采样间隔，是必须有的参数  n为采样次数，是可选的，默认值是1