AIX性能问题诊断及调优.docx
- 文档编号:23404518
- 上传时间:2023-05-16
- 格式:DOCX
- 页数:13
- 大小:652.63KB
AIX性能问题诊断及调优.docx
《AIX性能问题诊断及调优.docx》由会员分享,可在线阅读,更多相关《AIX性能问题诊断及调优.docx(13页珍藏版)》请在冰豆网上搜索。
AIX性能问题诊断及调优
在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-xsleep10
通过tprof可以看出占用CPU排名靠前进程。
如果rootcause还没有找到,那么便使出大招,收trace数据。
在收集trace数据前请先注意以下原则:
收集trace数据会对当前系统负载有影响,在CPU已经达到99%时,再收集trace有可能把操作系统搞夯。
一定要等到问题重现时收集trace,由于trace产生数据量巨大,因此要收集有效时间段trace。
如果不确定问题什么时候重现,可以写个判断脚本,收集循环trace。
用root用户进行trace收集
需要预估trace数据大小,然后根据预估空间,在操作系统上找一个空间较大地方存放数据。
trace数据大小可以用下列公式算出:
预估数据大小=逻辑CPU个数*10MB
(其中逻辑CPU个数可以用vmstat|grep-ilcpu命令查看)
在了解上述原则后,我们开始收集trace数据。
trace-anl-Call-T20M-L40M-o/bigFS/trace.raw
sleep10
trcstop
在执行完上述收集命令后,会生成traceraw文件。
下面对trace数据进行转换:
trcrpt-r-Calltrace.raw>trace.r
再用curt进行数据处理:
curt-itrace.r-ocurt.out-pest
此时产生一个curt.out文件,可以直接进行阅读。
首先可以从“SystemSummary”字段看到各种类型进程分别占用CPU比例。
然后从“ApplicationSummary”可以看到应用占用CPU排名。
也可以从“SystemCallsSummary”可以看到系统函数调用排名情况。
OK,到此我们便把这三把斧拍完了,那么我们来讨论一个真实案例,来从中看看这三把斧是怎么拍。
故障描述:
生产环境CPU使用率高,导致应用程序运行缓慢,批量程序无法按时完成。
系统环境:
AIX6100-07-05
处理过程:
Step1,使用topas查看,发现CPU使用率很高,其中大部分为Kern%占用
Step2,收集tprof数据,tprof-skeuj-xsleep10,找到占用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#9EBADF,该报错表述有无效文件描述符,经查发现这进程会调用close函数,把文件描述符从0到65533文件全部关闭一遍。
也就是说应用进程在调用大量close()函数导致系统kernel使用率飙升!
这也就把耗资源账伪造到了kernel头上。
最终升级应用程序解决了该问题。
类别二:
内存
下面我们来讨论内存使用情况,首先也可以使用topas命令进行内存使用情况查看。
从topas输出中可以看到物理内存共有64GB,pagingspace共有16个GB。
其中物理内存部分:
计算内存使用了27%,文件系统缓存使用了9%。
那么问题来了,真正用于运算内存是多少呢?
答案是物理内存27%。
切记一定不要把文件系统缓存使用当成内存真实消耗。
因此当有新内存申请时,文件系统缓存是可以被换出来。
那么一般来看,当计算内存达到90%时,则系统就会有性能问题;当达到95%以上,一般就会产生内存换页,这时就会把物理内存中数据换到了pagingspace中,而如果短时间内有大量换页产生,就很有可能引起操作系统夯,而如果在有HACMP或者oracleRAC集群环境中,就有可能导致集群强制把操作系统重启。
因此对计算内存监控非常重要。
说到内存,不得不说是svmon这个命令,这个命令可以查看更细内存使用情况,例如每个进程占用多少内存等等信息。
可以用svmon-G命令查看内存整体使用情况。
那么问题又来了,这个输出应该怎么看?
图中virtual字段是真实消耗计算内存业面数,size是物理内存业面数,因此计算内存比值=/=27%。
那么如何查看每个进程所使用内存量呢?
可以用svmon-P
在下图中这个例子中可以看到计算内存使用量共有11804个4K页面+185910个64KB页面。
换算为4KB页面共有个。
但注意:
这些内存有些是这个进程独享,有些是多个进程共享,因此在进行总和分析时不能简单把所有内存值相加。
下面我们来看看占有内存排名情况,我们要按占用内存量由多到少进行排列,这个可以按如下方式进行(注意:
最后一列已经换算成MB):
那么对于目前AIX6.1和AIX7.1版本,常见几个建议调优参数如下:
-minperm%=3
-maxperm%=90
-maxclient%=90
-lru_=0
-defaultfromAIX6.1.lru_setto0makesrepageratestobeignoredwhen
determiningwhatkindofpagetosteal,meanswillbestealwhenaboveminperm.
-strict_maxperm%=0
另外,perfPMR也是收集性能数据常用工具,下载网址如下:
可以用perfPMR提供脚本进行memdetails.sh进行更详细内存数据收集。
也可以使用nmon对内存进行分析,可以看到一天内内存整体使用情况。
其中深红色为计算内存,淡蓝色为文件系统缓存,黄色为文件系统缓存。
也可以按进程看到占用内存情况。
类别三:
I/O
谈起I/O不可避免要首先了解LVM相关一些技巧。
我们先谈谈lvmapping关系,这个东西说起来很简单,但实际上它和I/O性能和LV误删后恢复有密切关系,因此了解清楚LV映射对于系统运维有很大帮助。
可以通过lslv-m
这个排序是按着LP编号进行,这个顺序很重要,如果lv被误删后,可以根据这个排序把lv重建回来。
通过命令也可以看到详细分布信息。
通过readvgda
因此经常备份vgda信息对于灾难恢复很有必要。
通过getlvcb命令可以得到LVCB信息。
在了解完了LV分布后,我们回到性能监控上,iostat是一个很好用命令。
通过这个命令可以看到每个磁盘繁忙程度、响应时间、是否有I/O排队等信息。
topas-D也可以看到磁盘相关信息。
但在topas输出中一定注意CPU中idle%是否较高,由于idle%说明CPU在等待I/O,因此如果有idle%数值时,一定检查一下存储盘是否有问题。
如果要抓取I/O详细信息,可以用命令进行数据抓取。
-Oall-o;
sleep30;
trcstop
结束语
本次从AIXCPU、内存、I/O三个方面探讨了相关问题诊断及调整,可以当作抛砖引玉,供大家进行讨论参考。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- AIX 性能 问题 诊断