AIX性能问题诊断及调优.docx

《AIX性能问题诊断及调优.docx》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、在AIX日常运维中，性能问题一直是一个很重要的问题，为了让操作系统能正常平稳高效的运行，便需要一些武功秘籍来进行快速定准并解决问题，本次我们便来讨论一下我们可以用到的武功秘籍。所谓性能问题，主要几种在CPU、内存、I/O三个大类别，因此我们分类进行讨论。类别一：CPU检查系统的三把斧头一招便是topas，这个是最常用也是最有效的一招，通过topas的输出可以看到CPU的使用情况。从topas的输出我们主要关注如下4个指标：User%：主要是应用程序消耗CPU的百分比Kern%：主要是操作系统本身消耗CPU的百分比Wait%：

2、主要是有I/O问题时，CPU等待I/O的百分比Idle%：那么这个一定是空闲的CPU了那么判定系统忙不忙的一个指标为Idle%，正常情况下，Idle%的值如果低于10%，则这个系统的CPU就需要注意了，此时关注一下是User%高还是Kern%高，如果是User%高，则说明是应用程序占用CPU较多，反之则说明操作系统本身占用CPU较高。(但是请注意：并不是所有Kern%高都是操作系统本身导致的，也有可能是应用程序调用了系统本身的函数，这样也会把这部分消耗算在Kern%头上)在拍完第一板斧后，我们继续向下分析，拍第二板斧trpo

3、f，这个可以理解为精简版的trace，一般情况下执行这个命令对系统负载影响不太大，因此可以用这个工具先粗略看一下相关的进程。tprof-skeuj-xsleep10通过tprof可以看出占用CPU排名靠前的进程。如果rootcause还没有找到，那么便使出大招，收trace数据。在收集trace数据前请先注意以下原则：①收集trace数据会对当前系统的负载有影响，在CPU已经达到99%时，再收集trace有可能把操作系统搞夯。②一定要等到问题重现时收集trace，由于trace产生的数据量巨大，因此要收集有效时间段的trac

4、e。如果不确定问题什么时候重现，可以写个判断脚本，收集循环trace。③用root用户进行trace收集④需要预估trace数据的大小，然后根据预估的空间，在操作系统上找一个空间较大的地方存放数据。trace数据的大小可以用下列公式算出：预估数据大小=逻辑CPU的个数*10MB(其中逻辑CPU的个数可以用vmstat

5、grep-ilcpu命令查看)在了解上述原则后，我们开始收集trace数据。trace-anl-Call-T20M-L40M-o/bigFS/trace.rawsleep10trcstop在执行完上述收集命令后

6、，会生成trace的raw文件。下面对trace数据进行转换：trcrpt-r-Calltrace.raw>trace.r再用curt进行数据处理：curt-itrace.r-ocurt.out-pest此时产生一个curt.out文件，可以直接进行阅读。首先可以从“SystemSummary”字段看到各种类型的进程分别占用CPU的比例。然后从“ApplicationSummary”可以看到应用占用CPU的排名。也可以从“SystemCallsSummary”可以看到系统函数调用排名情况。OK，到此我们便把这三把斧拍完了，那

7、么我们来讨论一个真实的案例，来从中看看这三把斧是怎么拍的。故障描述：生产环境CPU使用率高，导致应用程序运行缓慢，批量程序无法按时完成。系统环境：AIX6100-07-05处理过程：Step1，使用topas查看，发现CPU使用率很高，其中大部分为Kern%占用Step2，收集tprof数据，tprof-skeuj-xsleep10，找到占用CPU最高的两个进程。/cd41/cdunix4100/ndm/bin/ndmsmgr/cd41/cdunix4100/ndm/bin/cdpmgrStep3，收集trace数据，并进行

8、分析，发现绝大多数是系统调用。当时以为是操作系统的BUG或者操作系统本身导致的，初步判断和应用程序没有关系，但后来证明当时这个想法是错误的，这也说明并不是所有kernel高是由于系统本身造成的，如果应用程序调用系统本身函数，也算在kernel头上。JStep4，通过curt文件输出，看到占用kernel最高的是paged_ds_start函数。Step5，分析调用paged_ds_start函数的进程为ndmsmgr，这是一个应用的进程!Step6，那么分析ndmsmgr为什么会调用较高的kernel运算。使用truss命令

9、跟踪这个进程。经分析这个进程在对文件进行操作完成后对文件执行close操作时有报错，返回值为ERR#9EBADF，该报错表述有无效的文件描述符，经查发现这进程会调用close函数，把文件描述符从0到65533的文件全部关闭一遍。也就是说应用进程在调用大量的close()函数导致系统kern