免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 3209 | 回复: 5

AIX topas 命令详解_带图 [复制链接]

论坛徽章:
0
发表于 2011-02-18 15:01 |显示全部楼层
AIX操作系统的最全面动态,而又查看便利的性能视图就是topas命令了,下面以topas输出为例,对AIX系统的性能监控做扼要描写,供运维工程师和系统治理员们参考。 \r\n另:1.操作系统报错信息errpt查看。2.磁盘空间使用率采取df查看。这里主要剖析性能问题。 \r\n执行topas命令后如图所示: \r\n#topas \r\n \r\n区域1:反应CPU使用率和工作状态。 \r\nKernel:\r\n解释:操作系统的内核占用的CPU时间比率。\r\n操作系统作为基本软件,为运用程序支撑和服务的同时,本身的运行也需要必定的CPU和内存资源(顺便提到内存资源,后面不再论述这个内容了),特殊是内存资源,系统负载越重,相应的内核占用的CPU和内存资源也会越多。一般来说,内核占用的CPU时间不会太多的。一般小于运用的CPU使用率。 \r\nUser:\r\n解释:用户进程占用的CPU时间比率。\r\n这个为CPU使用率的要害数值。该使用率反映了用户在操作系统基本上运行的各种软件占用的CPU时间比率的总和。一般来说,如果User+Kernel持续大于70%,即可以以为系统可能存在CPU上的严重性能问题。 \r\nWait\r\n解释:CPU处于等候状况占CPU时间的比率。\r\nCPU的期待一般都为期待IO的响应,众所周知,目前盘算机的重要瓶颈都在IO。利用程序履行的时候,须要读写磁盘等外部存储的数据,过程就会发起IO恳求后等候IO完成。这个等候的进程占用CPU时光就是wait。当这个值很高的时候,就阐明IO来不及响应很多的IO要求,这个时候,就只能从IO层面想措施优化了。 \r\nIdle:\r\n说明:CPU空闲时间比率,这个就不用说了吧。就是CPU多少时间比率在闲着。\r\nCPU占用率出问题的主要可能原因:数据库服务器履行某一个SQL或者存储进程(存储过程就是封装起来的sql程序包而已)须要大批的运算(一般为软件设计不公道)。或者利用程序中存在异常的处所,比如逝世循环,或者其他写程序时的逻辑过错导致。一般程序出错会导致一个CPU被全体占用,比如上述的20%占用的原因就是一个交易程序长期占用一个CPU全体时光片(系统共计5个CPU)。 \r\n区域2:反映网络使用率的状况。 \r\nNetwok;列出了网卡接口,KBPS即每秒钟多少KB(千字节) I-Pack每秒钟输入的数据包个数, O-Pack 每秒钟输出的数据包个数  KB-In每秒钟输进的字节数 KB-Out每秒钟输出的字节数。 \r\n当我们发明网络拥堵时(出现网卡传输失效的报错,即网卡发送数据包失败。或者网络响应显明变慢的时候,如果CPU没有问题,那么请检讨网络流量)发明某一个网卡的KBPS持续大于四位数,甚至五位数时(这个值要是网卡千兆还是百兆而定)。就要看看这个网卡是什么网卡,在处置什么业务了。在命令行执行netstat ?in 查看对应en*接口的ip地址,通过ip地址看看是带官网卡还是生产服务网卡流量高。然后通过netstat ?v en* 看看网卡的具体工作状况,出现了多少错包,冲突包,crc校验错或者网络重置过等信息。上述信息请具体看netstat ?v en*的输出.如果涌现大量crc,错包的话,可能网线有问题或者接触不良。 \r\n如果上述均正常,而网络反映慢,则有可能是交流机拥堵。 \r\n网络涌现问题的可能原因:通过百兆的带管网加载大量数据(以前呈现过),大量队列的长时间的ftp传输,或者网线,交流机问题等。\r\n区域3:反映磁盘使用率的状况。 \r\nDisk  Busy%磁盘忙碌的百分比,即磁盘能满足的最大IOPS(每秒IO操作数)和当前IO数目的比率。其他的参数不再说明。看文生义即可。 \r\n一般主要看磁盘的Busy%,当磁盘的Busy%持续大于85%时,即以为磁盘相当忙碌,已经可能要出问题了。当然,自己知道已经断定要发生大量IO操作的内容则不必在意,等其完成即可。 \r\n涌现问题的原因:运用服务器上面写日志进程或者查询日志的进程大量读写日志,导致磁盘忙碌率高,或者其他程序频繁读写磁盘导致。系统中hdisk0,hdisk1一般为系统盘,内置SCSI磁盘的相对IOPS是较低的。很轻易满负荷运行。 \r\n区域4:反映进程信息的状态。 \r\nName:进程的名称,即过程被执行时启动的二进制文件的名称。 \r\nPID,进程的ID,进程的ID在系统中唯一,是我们懂得跟踪进程信息主要数值。 \r\n跟踪进程的CPU使用,磁盘IO读写,进程的内存和pagingspace占用等等均需要使用。 \r\nCPU%进程占用CPU时光的比率。 \r\nPgSp,进程占用的pagingspace的空间大小。 \r\nOwner进程的属主,即由哪个操作用户用户启动了这个进程。 \r\n在topas中,默认是列出占用cpu最高的前几个的进程信息供参考,如果前面第一区域的的CPU使用率连续高,就要看看这里是那个进程占用了大量的CPU资源,看看是哪个用户的进程,如果自己执行的,则杀掉或者找项目组解决即可。 \r\n区域5:反应内存页面和换页空间信息的状态。 \r\n换页空间即磁盘上的空间,在AIX操作体系中用来做内存空间应用。具体的理论就不再论述了,具体信息请参阅操作系统内容。磁盘空间的速度当然相比内存,慢了不止10倍。所以,只是内存页面的一个暂时寄存地,寄存的还是那些长期不怎么用到的内存页面而已。假如paging大批呈现,这时候就有麻烦了,阐明:内存不够用了! \r\n该区域重要关注PageIn,PageOut假如这两个数值均大于三位数,并且长期大于这个数值,在技巧上叫做内存颠簸,即不停的把内存页面换到磁盘空间上,又从磁盘空间把内存页面读进来,系统的内存应用效力变的极差,体系响应性能也变慢了。 \r\n这个信息也可以用vmstat来看,pi和po列即与这里相对应。当然,如果只是有页面出,或者只有页面进,或者短时间的一些页面换进换出,则没有什么问题,关注一下即可。 \r\n区域6:反映内存使用的信息。 \r\nReal,MB操作系统实际拥有的内存的总量,单位是MB。 \r\n%Comp,计算型内存占用比率,%Noncomp非计算型内存占用的比率。 \r\n%Client也为非计算型内存,Noncomp包涵Client型内存,jfs文件系统使用的内存为noncomp,为了区分,jfs2和nfs使用的内存为Client。 \r\n计算型内存就是进程实际使用的内存,例如我们写程序的时候malloc内存,或者在排序中使用了堆栈,进程中变量数值都需要在内存中保留,这部分内存为盘算型内存(论述不全面,仅供参考)。而操作系统在进行文件读写,需要的io缓冲区,或者我们在写程序的时候,打开文件,读写文件,均在文件缓冲区进行。(裸装备例外,CCCC的数据库采取RAC,数据的存储全体使用裸装备,在数据库服务器上,数据文件的缓冲在oracle的sga区的data buffer中(这个区域系统以为是盘算型内存),是不会占用非计算内存的。) \r\n导致内存出问题的可能原因很多。主要有:过程使用了更多的内存,例如,CCCC数据库服务器大批的oracle衔接使用了很多内存,或者数据库中执行的某一个sql脚本或者存储过程的履行需要大量的内存来完成其操作(特例库中呈现过这个情况,一个存储进程的执行导致操作系统内存被耗尽,pg也随之耗尽,操作系统主动执行PGSP_KILL,把该进程给干掉了,我也是第一次知道aix系统还有这个功效,呵呵)。第二个主要的问题就是内存泄露,内存泄露最简略的来说,就是申请了内存空间,使用后不再使用了,但是也没有开释。我们写程序的时候malloc,却没有free。这就导致了严重的问题,随着程序的执行,可用物理内存越来越少,最后就挂了,只好定期重启利用来解决。 \r\n操作系统的内存换页机制导致了程序中不用的内存页面最后都跑到pg上面往了,换页空间会持续增长的。因应用导致系统问题就是这么发生的。 \r\n区域7反应的是换页空间的使用率。 \r\n如果换页空间的使用率长期增加,就阐明体系内存不足,已经开端使用磁盘空间来缓冲内存了,如果PG应用率连续增长,或者大于50%,须要警戒(到50%在监控平台已经是重要告警啦!),并马上提交系统治理员剖析内存增加原因。假如该数值连续增加,系统必定会挂掉的!\r\n

论坛徽章:
0
发表于 2011-02-24 10:20 |显示全部楼层
很不错的资料了

论坛徽章:
0
发表于 2011-02-28 16:35 |显示全部楼层
先顶了噢。。。。。。。。。。

论坛徽章:
0
发表于 2011-03-08 13:10 |显示全部楼层
Thanks ! Up Up ............{:6_689:}

论坛徽章:
0
发表于 2011-03-09 10:18 |显示全部楼层
\r\n楼主还有什么好东东吗?共享出来一起进步

论坛徽章:
0
发表于 2011-03-09 15:52 |显示全部楼层
回复 ibm-sky 的帖子\n\n谢谢,乐意分享资料
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP