下面内容是参加的一门网络课程的一个章节脉络。自己再脉络基础上进行了扩展。

看图说话

1.平台综述

描述一个平台(linux,windows),这里说的平台，其实就是主机。衡量一个主机的好坏，主要从5方面入手即可。主机的用途不同，要求指标也会略有不同。

2.解决性能问题的一般步骤

解决线上问题的步骤，和医生诊断的情形进行类比。解决线上问题的过程，往往最耗时，最困难的地方，就是定位问题过程，往往伴随着迭代往复。尤其解决那些不易复现的问题，非常困难。我的处理方式是：对于性能问题，没有好的办法，针对任务类型，从主机和应用层面进行调优；对于业务BUG，只能先定位问题起点，设法在测试环境模拟出BUG发生。

3.指标获取及分析

这个阶段，可以类比为医生查看诊断报告。诊断报告，也分为两部分，静态信息（如身高，体重，性别），和动态信息（氨基酸比例，白细胞比例等）。对这些指标综合考虑，可以正确评价繁忙程度。

指的注意的时，日志是主机向我们传达的信息，非常重要。系统参数，影响着主机行为，也非常重要。

4.主机五要素

4.1 CPU

指标	命令	注意
总体负载(Load average)	uptime top sar -q	要综合考虑CPU合数
CPU使用率	sar -u vmstat( us sy id wa st)	当CPU使用率持续达到80%以上，那就说明服务器在高负荷运行，比较危险
用户进程的CPU使用率	sar -u	如果在总的CPU使用率中占比比较高，那说明系统在正常工作。如果CPU使用率很高，并且用户CPU占比高，那么就需要重点分析调整应用或数据库的CPU占用。
系统进程的CPU使用率	sar -u	花费在内核操作的CPU时间，比如硬中断和软中断。如果系统CPU时间持续很高，很可能是底层调用问题，比如网卡驱动。正常情况下系统CPU时间应该尽量小。
CPU等待IO的时间	sar -u	正常情况下，这个值应该很小。否则应该检查一下I/O是否正常。还有频繁的pagein、pageout。
CPU空闲时间	sar -u	这个在生产环境中当然越高越好啦。但有时候做压力测试，评估峰值，这个值如果保持很高，也令人头疼，说明CPU资源未能够充分利用
Nice time	sar -u	调整优先度的进程耗费的CPU时间，这个值很高的情况应该比较少见。
Interrupts中断	top(si:软中断,hi:硬中断)	中断有软硬中断之分，影响更大。CPU时间片切换也会产生中断，硬件状态变更也会产生中断，因为需要通知到操作内核，比如大家敲键盘会产生中断、网卡有数据包流入也会产生中断。中断很高，可能网络资源引起，或者说明内核代码或驱动有问题。
上下文切换	sar -w	可能是由于进程或线程起停过于频繁。
运行队列(r)	vmstat（r,b）

4.2内存性能信息

指标	命令	注意
Free空间	free -m sar -r
交换区SWAP	free -m vmstat -a sar -r
buffers	free -m sar -r
cache	free -m sar -r
换入换出	sar -B
虚拟内存VIRT	top
物理内存RES	top

4.3磁盘性能信息

传送速率	sar -b iostat	如果%util接近100%,表明i/o请求太多,i/o系统已经满负荷,磁盘可能存在瓶颈,一般%util大于70%,i/o压力就比较大,读取速度有较多的wait.同时可以结合vmstat查看查看b参数
传输数据量	sar -b iostat	%util:      一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的 svctm:   平均每次设备I/O操作的服务时间 await:    平均每次设备I/O操作的等待时间 avgqu-sz: 平均I/O队列长度
IOPS Input/Output Per Second)即每秒的输入输出量(或读写次数

本文转自 randy_shandong 51CTO博客，原文链接：http://blog.51cto.com/dba10g/1832281，如需转载请自行联系原作者