查看原文
其他

AIX 性能问题诊断及调优秘籍

崔增顺 twt企业IT社区 2022-07-03

在AIX日常运维中,性能问题一直是一个很重要的问题,为了让操作系统能正常平稳高效的运行,便需要一些武功秘籍来进行快速定准并解决问题。

所谓性能问题,主要几种在CPU、内存、I/O三个大类别,因此我们分类进行讨论。


类别一: CPU


检查系统的三把斧头一招便是topas,这个是最常用也是最有效的一招,通过topas的输出可以看到CPU的使用情况。

从topas的输出我们主要关注如下4个指标:

User% :主要是应用程序消耗CPU的百分比

Kern% :主要是操作系统本身消耗CPU的百分比

Wait% :主要是有I/O问题时,CPU等待I/O的百分比

Idle% :那么这个一定是空闲的CPU了


那么判定系统忙不忙的一个指标为Idle%,正常情况下,Idle%的值如果低于10%,则这个系统的CPU就需要注意了,此时关注一下是User%高还是Kern%高,如果是User%高,则说明是应用程序占用CPU较多,反之则说明操作系统本身占用CPU较高。(但是请注意:并不是所有Kern%高都是操作系统本身导致的,也有可能是应用程序调用了系统本身的函数,这样也会把这部分消耗算在Kern%头上)

在拍完第一板斧后,我们继续向下分析,拍第二板斧trpof,这个可以理解为精简版的trace,一般情况下执行这个命令对系统负载影响不太大,因此可以用这个工具先粗略看一下相关的进程。

tprof -skeuj -x sleep 10

通过tprof可以看出占用CPU排名靠前的进程。

如果root cause还没有找到,那么便使出大招,收trace数据。在收集trace数据前请先注意以下原则:

①收集trace数据会对当前系统的负载有影响,在CPU已经达到99%时,再收集trace有可能把操作系统搞夯。

②一定要等到问题重现时收集trace,由于trace产生的数据量巨大,因此要收集有效时间段的trace。如果不确定问题什么时候重现,可以写个判断脚本,收集循环trace。

③用root用户进行trace收集

④需要预估trace数据的大小,然后根据预估的空间,在操作系统上找一个空间较大的地方存放数据。trace数据的大小可以用下列公式算出:

预估数据大小=逻辑CPU的个数 * 10MB

(其中逻辑CPU的个数可以用vmstat | grep -i lcpu命令查看)

在了解上述原则后,我们开始收集trace数据。

trace -anl -C all -T 20M -L 40M -o /bigFS/trace.raw

sleep 10

trcstop


在执行完上述收集命令后,会生成trace的raw文件。

下面对trace数据进行转换:

trcrpt -r -C all trace.raw>trace.r

再用curt进行数据处理:

curt -i trace.r -o curt.out -pest

此时产生一个curt.out文件,可以直接进行阅读。首先可以从“System Summary”字段看到各种类型的进程分别占用CPU的比例。

然后从“Application Summary”可以看到应用占用CPU的排名。

也可以从“System Calls Summary”可以看到系统函数调用排名情况。

OK,到此我们便把这三把斧拍完了,那么我们来讨论一个真实的案例,来从中看看这三把斧是怎么拍的。

故障描述:

生产环境CPU使用率高,导致应用程序运行缓慢,批量程序无法按时完成。

系统环境:

AIX 6100-07-05

处理过程:

Step1,使用topas查看,发现CPU使用率很高,其中大部分为Kern%占用。

Step2,收集tprof数据,tprof -skeuj -x sleep 10,找到占用CPU最高的两个进程。

/cd41/cdunix4100/ndm/bin/ndmsmgr

/cd41/cdunix4100/ndm/bin/cdpmgr

Step3,收集trace数据,并进行分析,发现绝大多数是系统调用。当时以为是操作系统的BUG或者操作系统本身导致的,初步判断和应用程序没有关系,但后来证明当时这个想法是错误的,这也说明并不是所有kernel高是由于系统本身造成的,如果应用程序调用系统本身函数,也算在kernel头上。

Step4,通过curt文件输出,看到占用kernel最高的是paged_ds_start函数。

Step5,分析调用paged_ds_start函数的进程为ndmsmgr,这是一个应用的进程!

Step6,那么分析ndmsmgr为什么会调用较高的kernel运算。使用truss命令跟踪这个进程。经分析这个进程在对文件进行操作完成后对文件执行close操作时有报错,返回值为ERR#9 EBADF,该报错表述有无效的文件描述符,经查发现这进程会调用close函数,把文件描述符从0到65533的文件全部关闭一遍。也就是说应用进程在调用大量的close()函数导致系统kernel使用率飙升!这也就把耗资源的账伪造到了kernel头上。

最终升级应用程序解决了该问题。


类别二:内存


下面我们来讨论内存的使用情况,首先也可以使用topas命令进行内存使用情况的查看。

从topas的输出中可以看到物理内存共有64GB,paging space共有16个GB。其中物理内存部分:计算内存使用了27%,文件系统缓存使用了9%。那么问题来了,真正用于运算的内存是多少呢?答案是物理内存的27%。切记一定不要把文件系统缓存的使用当成内存的真实消耗。因此当有新的内存申请时,文件系统的缓存是可以被换出来的。那么一般来看,当计算内存达到90%时,则系统就会有性能问题;当达到95%以上,一般就会产生内存换页,这时就会把物理内存中的数据换到了paging space中,而如果短时间内有大量的换页产生,就很有可能引起操作系统夯,而如果在有HACMP或者oracle RAC集群环境中,就有可能导致集群强制把操作系统重启。因此对计算内存的监控非常重要。

说到内存,不得不说的是svmon这个命令,这个命令可以查看更细的内存使用情况,例如每个进程占用多少内存等等信息。

可以用svmon -G命令查看内存的整体使用情况。那么问题又来了,这个输出应该怎么看?图中virtual字段是真实消耗的计算内存的业面数,size是物理内存的业面数,因此计算内存的比值=4406839/16777216=27%。

那么如何查看每个进程所使用的内存量呢?可以用svmon -P <PID>来进行查看。在下图中这个例子中可以看到计算内存的使用量共有11804个4K页面+185910个64KB页面。换算为4KB页面共有2986364个。但注意:这些内存有些是这个进程独享的,有些是多个进程共享的,因此在进行总和分析时不能简单的把所有内存值相加。

下面我们来看看占有内存的排名情况,我们要按占用内存的量由多到少进行排列,这个可以按如下方式进行(注意:最后一列已经换算成MB):

那么对于目前AIX 6.1和AIX 7.1版本,常见的几个建议调优的参数如下:

- minperm% = 3

- maxperm% = 90

- maxclient% = 90

- lru_file_repage=0

- default from AIX 6.1. lru_file_repage set to 0 makes repage rates to be ignored when

determining what kind of page to steal, means filecache will be steal when above minperm.

- strict_maxperm%=0


另外,perfPMR也是收集性能数据常用的工具,下载网址如下:

ftp://ftp.software.ibm.com/aix/tools/perftools/perfpmr

可以用perfPMR提供的脚本进行memdetails.sh进行更详细的内存数据收集。

也可以使用nmon对内存进行分析,可以看到一天内的内存整体使用情况。其中深红色的为计算内存,淡蓝色的为文件系统缓存,黄色的为文件系统缓存。

也可以按进程看到占用内存的情况。


类别三: I/O


谈起I/O不可避免的要首先了解LVM相关的一些技巧

我们先谈谈lv的mapping关系,这个东西说起来很简单,但实际上它和I/O的性能和LV误删后的恢复有密切的关系,因此了解清楚LV映射对于系统运维有很大的帮助。

可以通过lslv -m <lvname>看到lv的分布情况。这个排序是按着LP的编号进行的,这个顺序很重要,如果lv被误删后,可以根据这个排序把lv重建回来。

通过fileplace命令也可以看到详细的分布信息。

通过readvgda<hdisk>可以通过磁盘读取到VGDA的信息,这里边包含了所有LV的mapping信息。因此经常备份vgda信息对于灾难恢复很有必要。

通过getlvcb命令可以得到LVCB的信息。

在了解完了LV的分布后,我们回到性能监控上,iostat是一个很好用的命令。

通过这个命令可以看到每个磁盘的繁忙程度、响应时间、是否有I/O排队等信息。

topas -D也可以看到磁盘的相关信息。但在topas输出中一定注意CPU中的idle%是否较高,由于idle%说明CPU在等待I/O,因此如果有idle%数值时,一定检查一下存储盘是否有问题。 

如果要抓取I/O的详细信息,可以用filemon命令进行数据抓取。

filemon -O all -o filemon.out;

sleep 30;

trcstop


结束语

本文从AIX CPU、内存、I/O三个方面探讨了相关的问题诊断及调整,可以当作抛砖引玉,供大家进行讨论参考。


长按二维码关注公众号

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存