下面内容是参加的一门网络课程的一个章节脉络。自己再脉络基础上进行了扩展。
看图说话
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)即每秒的输入输出量(或读写次数 | ||
本文出自 “简单” 博客，请务必保留此出处http://dba10g.blog.51cto.com/764602/1832281
原文地址：http://dba10g.blog.51cto.com/764602/1832281
