2022年aixtopas命令详解[参 .pdf

《2022年aixtopas命令详解[参 .pdf》由会员分享，可在线阅读，更多相关《2022年aixtopas命令详解[参 .pdf（3页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、区域 1：反映 CPU 使用率和工作状况。Kernel：说明：操作系统的内核占用的CPU 时间比率。操作系统作为基础软件，为应用程序支持和服务的同时，本身的运行也需要一定的 CPU 和内存资源 （顺便提到内存资源，后面不再阐述这个内容了） ，特别是内存资源， 系统负载越重， 相应的内核占用的CPU和内存资源也会越多。一般来说，内核占用的CPU 时间不会太多的。一般小于应用的CPU 使用率。User：说明：用户进程占用的CPU 时间比率。这个为CPU 使用率的关键数值。该使用率反映了用户在操作系统基础上运行的各种软件占用的CPU 时间比率的总和。 一般来说，如果User+Kernel 连续大于

2、70%，即可以认为系统可能存在CPU 上的严重性能问题。 而我们的实际维护工作中，如果发现某一个CCCC 主机（ bjdb0261，bjdb0271 除外，这两个主机的负载一直比较高）的User+Kernel 大于 30%，就要看看下面的第四区域，看看是不是有进程持续占用了大量的CPU 资源，例如，某一个交易处理程序的 CPU 使用率持续在20%左右（曾经发生过） 。Wait 说明： CPU 处于等待状态占CPU 时间的比率。 CPU 的等待一般都为等待IO 的响应，众所周知，目前计算机的主要瓶颈都在 IO。应用程序执行的时候，需要读写磁盘等外部存储的数据，进程就会发起IO 请求后等待IO 完

3、成。这个等待的过程占用CPU 时间就是 wait。当这个值很高的时候，就说明IO 来不及响应很多的IO 请求，这个时候，就只能从IO 层面想办法优化了。Idle：说明： CPU 空闲时间比率，这个就不用说了吧。就是CPU 多少时间比率在闲着。 CPU 占用率出问题的主要可能原因：数据库服务器执行某一个SQL 或者存储过程（存储过程就是封装起来的sql 程序包而已）需要大量的运算（一般为软件设计不合理） 。或者应用程序中存在异常的地方，比如死循环，或者其他写程序时的逻辑错误导致。一般程序出错会导致一个CPU 被全部占用，比如上述的20%占用的原因就是一个交易程序长期占用一个CPU 全部时间片（系

4、统共计5 个 CPU） 。区域 2：反映网络使用率的状况。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 3 页 - - - - - - - - - Netwok；列出了网卡接口，KBPS 即每秒钟多少KB （千字节）I-Pack 每秒钟输入的数据包个数，O-Pack 每秒钟输出的数据包个数 KB-In 每秒钟输入的字节数KB-Out 每秒钟输出的字节数。当我们发现网络拥堵时（出现网卡传输失效的报错，即网卡发送数据包失败。或者网络响应明显变慢的时候，如果CPU 没有问题，

5、那么请检查网络流量）发现某一个网卡的KBPS 持续大于四位数，甚至五位数时（这个值要是网卡千兆还是百兆而定）。就要看看这个网卡是什么网卡，在处理什么业务了。在命令行执行netstat in 查看对应 en*接口的 ip 地址，通过ip 地址看看是带官网卡还是生产服务网卡流量高。然后通过netstat v en* 看看网卡的详细工作状态，出现了多少错包，冲突包，crc 校验错或者网络重置过等信息。上述信息请详细看netstat v en*的输出 .如果出现大量crc，错包的话， 可能网线有问题或者接触不良。如果上述均正常，而网络反应慢，则有可能是交换机拥堵。网络出现问题的可能原因：通过百兆的带管

6、网加载大量数据（以前出现过），大量队列的长时间的ftp 传输，或者网线，交换机问题等。区域 3：反映磁盘使用率的状况。Disk Busy% 磁盘繁忙的百分比，即磁盘能满足的最大IOPS（每秒 IO 操作数）和当前IO 数量的比率。其他的参数不再解释。望文生义即可。一般主要看磁盘的Busy%,当磁盘的 Busy%持续大于 85%时，即认为磁盘相当繁忙，已经可能要出问题了。当然，自己知道已经确定要产生大量IO 操作的内容则不必在意，等其完成即可。出现问题的原因：CCCC 的应用服务器上面写日志进程或者查询日志的进程大量读写日志，导致磁盘繁忙率高，或者其他程序频繁读写磁盘导致。系统中hdisk0 ，

7、hdisk1 一般为系统盘，内置SCSI 磁盘的相对IOPS 是较低的。很容易满负荷运行。区域 4：反映进程信息的状况。Name：进程的名称，即进程被执行时启动的二进制文件的名称。PID，进程的 ID，进程的 ID 在系统中唯一，是我们了解跟踪进程信息重要数值。跟踪进程的CPU 使用，磁盘 IO 读写，进程的内存和pagingspace占用等等均需要使用。CPU%进程占用 CPU时间的比率， PgSp，进程占用的pagingspace的空间大小。 Owner 进程的属主，即由哪个操作用户用户启动了这个进程。在 topas 中，默认是列出占用cpu 最高的前几个的进程信息供参考，如果前面第一区域

8、的的CPU 使用率持续高，就要看看这里是那个进程占用了大量的CPU 资源，看看是哪个用户的进程，如果自己执行的，则杀掉或者找项目组解决即可。区域 5：反映内存页面和换页空间信息的状况。换页空间即磁盘上的空间，在 AIX 操作系统中用来做内存空间使用。具体的理论就不再阐述了，详细信息请参阅操作系统内容。磁盘空间的速度当然相比内存，慢了不止10 倍。所以，只是内存页面的一个暂时存放地，存放的还是那些长期不怎么用到的内存页面而已。 如果 paging 大量出现，这时候就有麻烦了，说明：内存不够用了！该区域主要关注PageIn，PageOut如果这两个数值均大于三位数，并且长期大于这个数值，在技术上叫

9、做内存颠簸，即不停的把内存页面换到磁盘空间上，又从磁盘空间把内存页面读进来，系统的内存使用效率变的极差，系统响应性能也变慢了。这个信息也可以用vmstat来看， pi 和 po 列即与这里相对应。当然，如果只是有页面出，或者只有页面入，或者短时间的一些页面换入换出，则没有什么问题，关注一下即可。区域 7 就在这里一起说了，区域7 反映的是换页空间的使用率，如果换页空间的使用率长期增长，就说明系统内存不足，已经开始使用磁盘空间来缓冲内存了， 如果 PG使用率持续增长， 或者大于 50%， 需要警惕（到 50%在监控平台已经是主要告警啦！ ） ，并马上提交系统管理员分析内存增长原因。如果该数值持续

10、增长，系统一定会挂掉的！区域 6：反映内存使用的信息。Real，MB 操作系统实际拥有的内存的总量，单位是MB 。%Comp，计算型内存占用比率，%Noncomp 非计算型内存占用的比率。%Client 也为非计算型内存，Noncomp 包涵 Client 型内存， jfs 文件系统使用的内存为noncomp，为了区分， jfs2 和 nfs 使用名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 3 页 - - - - - - - - - 的内存为 Client。计算型内存

11、就是进程实际使用的内存，例如我们写程序的时候malloc 内存，或者在排序中使用了堆栈，进程中变量数值都需要在内存中保存，这部分内存为计算型内存（阐述不全面，仅供参考）。而操作系统在进行文件读写，需要的io 缓冲区，或者我们在写程序的时候，打开文件，读写文件，均在文件缓冲区进行。（裸设备例外， CCCC 的数据库采用RAC，数据的存储全部使用裸设备，在数据库服务器上，数据文件的缓冲在oracle的 sga区的 data buffer 中（这个区域系统认为是计算型内存），是不会占用非计算内存的。）我们日常监控在看这一部分的内存使用的，一般要看计算型内存是不是在增长，或者计算型内存大于了某一个临界

12、值，一般来说，按照 CCCC 目前的 VMO 配置，如果计算型内存大于80%是很危险的，有可能就导致大量pg 的使用而性能急剧恶化。导致内存出问题的可能原因很多。主要有： 进程使用了更多的内存，例如，CCCC 数据库服务器大量的oracle 连接使用了很多内存，或者数据库中执行的某一个sql 脚本或者存储过程的执行需要大量的内存来完成其操作（特例库中出现过这个情形，一个存储过程的执行导致操作系统内存被耗尽，pg 也随之耗尽，操作系统自动执行PGSP_KILL, 把该进程给干掉了，我也是第一次知道 aix 系统还有这个功能，呵呵） 。第二个主要的问题就是内存泄漏，内存泄漏最简单的来说，就是申请了

13、内存空间，使用后不再使用了，但是也没有释放。我们写程序的时候malloc，却没有 free。这就导致了严重的问题，随着程序的执行，可用物理内存越来越少，最后就挂了，只好定期重启应用来解决。操作系统的内存换页机制导致了程序中不用的内存页面最后都跑到pg 上面去了，换页空间会持续增长的。因应用导致系统问题就是这么产生的。CCCC 项目中不涉及NFS 操作，不再阐述。请大家平时没事的时候帮忙看看系统性能问题，如有异常，诸位好心里有数，不慌。我们也好及时响应处理。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 3 页 - - - - - - - - -