aix性能调整(编辑修改稿)

aix性能调整(编辑修改稿)内容摘要：

bindprocessor fdpr migratepv chdev chdev chdev chlv ifconfig setpri rmss revg 167。 性能检测流程图 虽然性能分析和调整没有绝对的准则，但我们可以遵循一些通用的流程。 检测系统性能的顺序非常重要，正确的顺序应该是： CPU、内存、 I/O、网络。 以下是性能检测的流程图： 图 1 性能分析流程图 \\Anlin\tech\知识库 \论文 \主机部 \99 二季度 \AIX 性能调整 (张大鹏 ).doc 第二章 CPU 的性能 现在从图 1 的最上方开始，分析 CPU的性能，并介绍一些分析和调整工具。 167。 进程管理 一个进程（ Process）是一个程序对某个数据集的执行过程，是分配资源的基本单位。 在 AIX 中，进程是在系统中由命令、 Shell 程序或其它进程启动的活动。 每个进程是由一个或多个线程（ Thread）组成的。 一个单线程的进程一次只能顺序地处理一个操作。 多线程控制使应用可以重叠处理操作，例如从终端读字符的同时写文件。 多线程控制还可以是应用 同时服务多个用户的请求。 调度算法 在多线程操作系统中，线程的调度算法非常重要。 AIX V4 支持三种线程调度算法： 先进先出（ SCHED_FIFO）调度算法 先进先出调度算法是一种非抢占式的调度算法。 线程一直占用 CPU直到运行结束，除非运行受到阻碍或自愿放弃 CPU。 直观看， FIFO 算法在一般意义上是公平的。 不过，对于那些执行时间较短的线程来说，如果它们在某些执行时间较长的线程之后到达，这它们将等待很长的时间。 因此，在实际操作系统中，很少单独使用 FIFO 算法。 只有 root 用户拥有的一些固定优先级 的线程才会采用 FIFO 调度算法。 轮转法（ SCHED_RR） 轮转法的基本概念是将 CPU的处理时间分成固定大小的时间片。 如果一个进程在被调度选中之后用完了系统规定的时间片，但未完成要求的任务，则它自行释放自己所占有的 CPU而排到就绪队列的末尾，等待下一次调度。 只有 root 用户可以设置某个线程使用这种调度算法。 其它算法（ SCHED_OTHER） \\Anlin\tech\知识库 \论文 \主机部 \99 二季度 \AIX 性能调整 (张大鹏 ).doc 是缺省的 AIX 线程调度算法。 它像轮转法一样将 CPU的处理时间分成固定大小的时间片，但每个线程的优先级却是不固定的。 每次时钟中断时，线程的优先级都要重新计算。 进程和线程的优先级 对于采用 SCHED_OTHER 调度算法的线程来说，它的优先级是非常重要的属性。 因为调度算法会根据优先级来分配 CPU资源。 在内核中，每个线程都有一个优先级的值。 这个优先级的值是一个正的整数，值的大小表示优先级的高低。 越小的优先级值代表越重要的线程，当调度选择一个线程分配给 CPU时，它总是选择优先级数值最小的线程。 线程的优先级可以是固定的，也可以是不固定的。 对于优先级不固定的线程来说，它的优先级由以下公式得出： 优先级＝用户线程的最小优先级＋线程 NICE 值＋ CPU使用惩罚因子 其 中用户线程的最小优先级是一个常数 40。 就是说，用户线程的优先级数值一定大于 40，优先级小于 40 的进程为系统进程。 线程 NICE 值的缺省值为 20，可以通过 nice 和 renice 命令进行设置。 CPU使用惩罚因子是一个整数，它是根据线程最近占用 CPU 的情况计算出来的。 每当 10ms 的 CPU时间片结束时，如果线程占用 CPU，那么 CPU 使用值（ C）就加 1，直到加到 120 为止。 167。 CPU性能分析 在进行性能分析时，我们要分析的第一个组件就是 CPU，这也是比较简单的一个部分。 分析的策略如下： vmstat 和 iostat 命令可以帮助确定系统的性能瓶颈是否为 CPU。 如果确定 CPU 为性能瓶颈，那么就要找出哪些进程或应用占用了过多的 CPU资源，这时要使用 ps 命令或 tprof 命令。 确定了过多占用 CPU资源的应用后，我们还要判断这种情况是正常的还是不正常的。 如果是不正常的，那么我们就需要采取各种办法来改善应用程序的性能，包括编程\\Anlin\tech\知识库 \论文 \主机部 \99 二季度 \AIX 性能调整 (张大鹏 ).doc 方式、库函数调用及编译器选项等。 vmstat 命令 vmstat 是要介绍的第一个工具，次命令能够提供关于各种系统资源及相关性能问题的非常快速和简洁的信息。 vmstat 命令可以报告出以下统计 信息：运行队列和等待队列中的内核进程、内存、 paging、磁盘、中断、系统调用、线程间切换（ Context Switch）和 CPU 活动。 其中 CPU 活动按百分比分成用户模式、系统模式、空闲时间和等待 I/O时间。 vmstat 命令可以找出三个方面可能的性能问题： CPU、内存和 I/O。 vmstat 命令的用法是： vmstat [ifs] [devices] [interval] [count] vmstat –s 加 –s 参数可以报告从系统启动到现在的 paging 和系统事件的概要信息。 输出形式如下： vmstat s 2895207 total address trans. faults 145740 page ins 83203 page outs 3436 paging space page ins 7844 paging space page outs 0 total reclaims 1260991 zero filled pages faults 5360 executable filled pages faults 1171187 pages examined by clock 35 revolutions of the clock hand 72712 pages freed by the clock 16984 backtracks 0 lock misses 1904 free frame waits 0 extend XPT waits 58771 pending I/O waits 111921 start I/Os 111921 iodones 12935949 cpu context switches 74569755 device interrupts \\Anlin\tech\知识库 \论文 \主机部 \99 二季度 \AIX 性能调整 (张大鹏 ).doc 0 software interrupts 0 traps 54273766 syscalls vmstat –f 加 –f 参数可以报告从系统启动到现在 fork出的进程或线程的数目。 vmstat –i 加 –i 参数可以报告从系统启动到现在或每个时间间隔内的设备中断情况。 输出形式如下： vmstat [interval] [count] vmstat 后面跟时间间隔和显示次数可以周期性地报告进程、 paging、内存和 CPU的利用情况。 下 面的 vmstat 输出中，我们可以看出一个占用 CPU 资源很多的程序启动和停止的过程。 \\Anlin\tech\知识库 \论文 \主机部 \99 二季度 \AIX 性能调整 (张大鹏 ).doc 在这个例子中我们可以发现，前三行的输出中 CPU空闲的比率为 99％。 然后一个占用 CPU资源很多的程序启动，此时 CPU空闲为 0，而 I/O 等待也为 0，可以看出 CPU资源明显不足。 该程序停止后， CPU的利用率又回到起始值。 要检查 CPU是否为性能瓶颈，我们应该关注 cpu下面的四列和 kthr（ Kernel Threads）下面的两列。 下面详细介绍这六列的含义。 CPU 列 表示在指定时间间隔内 CPU的利用情况。 us 列显示消耗在用户模 式的 CPU 时间的百分比。 UNIX 进程可以运行在用户模式，也可以运行在系统模式。 当运行在用户模式时，进程执行自己的应用代码，不需要内核资源来执行计算、管理内存或设置变量。 sy 列显示程序运行在系统模式的 CPU时间的百分比。 这包括内核进程和其它需要访问内核资源的进程所消耗的 CPU 时间。 如果一个进程需要内核资源，它必须执行一个系统调用，然后切换至系统模式，获得资源。 理想的 CPU工作时间应该是 100％，这在不需要共享 CPU的单用户系统下是正确的。 通常情况下，如果一个单用户系统的 us+sy 时间小于 90％，就可以 认为 CPU 不是性能瓶颈。 然而在多用户系统中，如果 us+sy 时间大于 80％，进程就要在运行队列中等待 CPU，响应时间和吞吐量都会受到影响，此时 CPU就可以被认为是性能瓶颈。 id列显示 CPU空闲或等待的百分比。 这个百分比中不包括等待磁盘 I/O 的时间。 如果当前没有进程需要运行，系统会分派一个叫做 wait 的进程给 CPU运行。 wa 列显示 CPU 等待磁盘 I/O 的空闲时间的百分比。 当 wait 进程运行时，如果存在至少一个为完成的磁盘 I/O， CPU 时间就记入 wa 列。 等待磁盘 I/O 的进程被放在等待队列，一旦该进程的 I/O。