linux排优命令
[*] 1、CPU
[*] 1.1、vmstate
[*] 1.2 、top
[*] 1.3、sar
[*] 2、内存
[*] 2.1、free
[*] 3、IO
[*] 3.1、iostat
[*] 4、网络
[*] 4.1 netstate
1、CPU
1.1、vmstate
用来获得有关进程、虚存、页面交换空间及 CPU活动的信息。这些信息反映了系统的负载情况
https://wiki.sankuai.com/download/attachments/852330669/image2017-4-17%2010%3A45%3A8.png?version=1&modificationDate=1492397108000&api=v2
r(procs)
b(procs)
swpd(memory)
free(memory)
buff(memory)
cache(memory)
si(swap)
so(swap)
运行和等待CPU时间片的进程数
ps:如果长期大于系统CPU个数，就说明CPU资源不足，可以考虑增加CPU
在等待资源的进程数
ps：正在等待I/O或者内存交换等
表示切换到内存交换区的内存数量（以KB为单位）
当前空闲的物理内存数量（以KB为单位）buffers cache的内存数量，一般对块设备的读写才需要缓冲page cached的内存数量，一般作文件系统的cached，频繁访问的文件都会被cached。如果cached值较大，就说明cached文件数较多。如果此时IO中的bi比较小，就说明文件系统效率比较好由磁盘调入内存，也就是内存进入内存交换区的数量由内存调入磁盘，也就是内存交换区进入内存的数量 bi(io)
bo(io)
in(system)
cs(system)
us(cpu)
sy(cpu)
id(cpu)
wa(cpu)
st(cpu)
从块设备读入的数据总量（即读磁盘，单位KB/秒）写入到块设备的数据总量（即写磁盘，单位KB/秒）在某一时间间隔中观察到的每秒设备中断数；每秒产生的上下文切换次数用户进程消耗CPU的时间百分比。us的值比较高时，说明用户进程消耗的CPU时间多，如果长期大于50%，需要考虑优化程序啥的 内核进程消耗CPU的时间百分比。sy的值比较高时，就说明内核消耗的CPU时间多；如果us+sy超过80%，就说明CPU的资源存在不足。
sy 值高时，表示系统花费了更多的时间在进行线程切换， JAVA 应用造成这种现象的主要原因是启动的线程比较多，且这些线程多数都处于不断的阻塞和执行状态的变化过程中，导致系统不断的切换线程，产生大量的上下文切换
CPU处在空闲状态的时间百分比；IO等待所占的CPU时间百分比。wa值越高，说明IO等待越严重。如果wa值超过20%，说明IO等待严重虚拟机占用的时间百分比
1.2 、top
https://wiki.sankuai.com/download/attachments/852330669/image2017-4-17%2011%3A18%3A35.png?version=1&modificationDate=1492399115000&api=v2
第三行：
us
sy
ni
id
wa
hi
si
st
表示用户进程处理所占的百分比。
用户进程的CPU消耗比率应该在 65%-70%
表示系统内核线程处理所占的百分比
内核的CPU消耗比率应该为30%-35%
表示被"nice"命令改变优先级的任务所占百分比表示空闲时间所占的百分比表示在执行过程中等待IO所占的百分比表示硬件中断所占的百分比表示软件中断所占百分比st 的全称是 Steal Time ，就是 Xen Hypervisor 分配给运行在其它虚拟机上的任务的实际 CPU 时间第四行Mem：
total
used
free
buffers
物理内存总量使用中的内存总量空闲内存总量 缓存的内存量第五行Swap：
total
used
free
cached
交换区总量使用的交换区总量空闲交换区总量缓冲的交换区总量
cache 和 buffer的区别：
Cache：高速缓存，是位于CPU与主内存间的一种容量较小但速度很高的存储器。由于CPU的速度远高于主内存，CPU直接从内存中存取数据要等待一定时间周期，Cache中保存着CPU刚用过或循环使用的一部分数据，当CPU再次使用该部分数据时可从Cache中直接调用,这样就减少了CPU的等待时间,提高了系统的效率。Cache又分为一级Cache(L1 Cache)和二级Cache(L2 Cache)，L1 Cache集成在CPU内部，L2 Cache早期一般是焊在主板上,现在也都集成在CPU内部，常见的容量有256KB或512KB L2 Cache。
Buffer：缓冲区，一个用于存储速度不同步的设备或优先级不同的设备之间传输数据的区域。通过缓冲区，可以使进程之间的相互等待变少，从而使从速度慢的设备读入数据时，速度快的设备的操作进程不发生间断。
1.3、sar
输出cpu采样，每一秒输出一次，连续输出30次：
https://wiki.sankuai.com/download/attachments/852330669/image2017-4-17%2014%3A32%3A33.png?version=1&modificationDate=1492410753000&api=v2
cpu
%user
%nice
%system
%iowait
%steal
%idle
all 表示统计信息为所有 CPU 的平均值显示在用户级别(application)运行使用 CPU 总时间的百分比显示在用户级别，用于nice操作，所占用 CPU 总时间的百分比在核心级别(kernel)运行所使用 CPU 总时间的百分比显示用于等待I/O操作占用 CPU 总时间的百分比管理程序(hypervisor)为另一个虚拟进程提供服务而等待虚拟 CPU 的百分比显示 CPU 空闲时间占用 CPU 总时间的百分比
%iowait与cpu的认知
表示在一个采样周期内有百分之几的时间属于以下情况：CPU空闲、并且有仍未完成的I/O请求。对 %iowait 常见的误解有两个： 一是误以为 %iowait 表示CPU不能工作的时间， 二是误以为 %iowait 表示I/O有瓶颈。首先 %iowait 升高并不能证明等待I/O的进程数量增多了，也不能证明等待I/O的总时间增加了。 例如，在CPU繁忙期间发生的I/O，无论IO是多还是少，%iowait都不会变；当CPU繁忙程度下降时，有一部分IO落入CPU空闲时间段内，导致%iowait升高。 再比如，IO的并发度低，%iowait就高；IO的并发度高，%iowait可能就比较低。可见%iowait是一个非常模糊的指标，如果看到 %iowait 升高，还需检查I/O量有没有明显增加，avserv/avwait/avque等指标有没有明显增大，应用有没有感觉变慢，如果都没有，就没什么好担心的。
2、内存
2.1、free
https://wiki.sankuai.com/download/attachments/852330669/image2017-4-17%2015%3A50%3A36.png?version=1&modificationDate=1492415436000&api=v2
第一行：
total
used
free
shared
buffers
cached
表示系统可使用的物理内存的总量已经被分配的内存（buffers＋cached＋buffer/cache-used）未分配的物理内存
已经被系统分配而未使用的buffer已经被分配而未使用的cache内存
第二行：
used
free
已经被应用程序真正使用掉的buffer和cache内存可以被应用程序使用的内存(第一行的－》free＋buffers＋cached)
3、IO
3.1、iostat
-C 显示CPU使用情况
-d 显示磁盘使用情况
-k 以 KB 为单位显示
-m 以 M 为单位显示
-N 显示磁盘阵列(LVM) 信息
-n 显示NFS 使用情况
-p[磁盘] 显示磁盘和分区的情况
-t 显示终端和CPU的信息
-x 显示详细信息
-V 显示版本信息
https://wiki.sankuai.com/download/attachments/852330669/image2017-4-17%2016%3A15%3A58.png?version=1&modificationDate=1492416958000&api=v2
指标详解：
rrqm/s：每秒进行 merge 的读操作数目.即 delta(rmerge)/s
wrqm/s：每秒进行 merge 的写操作数目.即 delta(wmerge)/s
r/s： 每秒完成的读 I/O 设备次数.即 delta(rio)/s
w/s：每秒完成的写 I/O 设备次数.即 delta(wio)/s
rsec/s：每秒读扇区数.即 delta(rsect)/s
wsec/s：每秒写扇区数.即 delta(wsect)/s
rkB/s：每秒读K字节数.是 rsect/s 的一半,因为每扇区大小为512字节.(需要计算)
wkB/s： 每秒写K字节数.是 wsect/s 的一半.(需要计算)
avgrq-sz：
平均每次设备I/O操作的数据大小 (扇区).delta(rsect+wsect)/delta(rio+wio)
ps：
类似于平均每人所买的东西多少
avgqu-sz：
平均I/O队列长度.即 delta(aveq)/s/1000 (因为aveq的单位为毫秒).
ps：类似于单位时间里平均排队人的个数
await：
平均每次设备I/O操作的等待时间 (毫秒). 排队的时间＋处理的时间。即 delta(ruse+wuse)/delta(rio+wio)
ps:类似于平均每人的等待时间
svctm：
平均每次设备I/O操作的服务时间 (毫秒).即 delta(use)/delta(rio+wio)
ps：类似于收银员的收款速度
%util：
一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的，即 delta(use)/s/1000 (因为use的单位为毫秒)
ps:类似于收款台前有人排队的时间比例
如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
idle小于70% IO压力就较大了，一般读取速度有较多的wait。
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比，高过30%时IO压力高)。
另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。
avgqu-sz 也是个做 IO 调优时需要注意的地方，这个就是直接每次操作的数据的大小，如果次数多，但数据拿的小的话，其实 IO 也会很小。如果数据拿的大，才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s。也就是讲，读定速度是这个来决定的。
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水
4、网络
4.1 netstate
参数汇总
折叠原码
-ashow both listening and none-listening sockets.默认是不显示listening sockets
-t仅显示tcp相关默认是都显示
-u仅显示udp相关默认是都显示
-n拒绝显示别名，显示数字
-l仅列出有在Listen(监听)的服务状态
-p显示建立相关连接的程序名 需要sudo才能看到其他用户起动的程序pid
-r显示路由表
-c每隔一段时间(秒)，执行该netstat命令
-i显示各个网络接口的状况
-s按照协议进行统计
https://wiki.sankuai.com/download/attachments/852330669/image2017-4-17%2018%3A5%3A1.png?version=1&modificationDate=1492423501000&api=v2
https://wiki.sankuai.com/download/attachments/852330669/image2017-4-19%2015%3A2%3A18.png?version=1&modificationDate=1492585338000&api=v2https://wiki.sankuai.com/download/attachments/852330669/image2017-4-19%2015%3A3%3A28.png?version=1&modificationDate=1492585408000&api=v2
CLOSED没有使用这个套接字LISTEN套接字正在监听连接[调用listen后]SYN_SENT套接字正在试图主动建立连接[发送SYN后还没有收到ACK]SYN_RECEIVED正在处于连接的初始同步状态[收到对方的SYN，但还没收到自己发过去的SYN的ACK]ESTABLISHED连接已建立CLOSE_WAIT远程套接字已经关闭：正在等待关闭这个套接字[被动关闭的一方收到FIN]FIN_WAIT_1套接字已关闭，正在关闭连接[发送FIN，没有收到ACK也没有收到FIN]CLOSING套接字已关闭，远程套接字正在关闭，暂时挂起关闭确认[在FIN_WAIT_1状态下收到被动方的FIN]LAST_ACK远程套接字已关闭，正在等待本地套接字的关闭确认[被动方在CLOSE_WAIT状态下发送FIN]FIN_WAIT_2套接字已关闭，正在等待远程套接字关闭[在FIN_WAIT_1状态下收到发过去FIN对应的ACK]TIME_WAIT这个套接字已经关闭，正在等待远程套接字的关闭传送
排查或者调优需要用的三大工具：iftop、iotop、htop
iftop，iotop，htop三者主要做以下用处：
iftop
用来显示本机网络流量情况及各相互通信的流量集合。iftop通常适用于代理服务器和iptables服务器使用。
iotop
是一个用来监视磁盘I/O 使用状况的 top 类工具，iotop是使用Python语言编写而成，目前iotop可从其官方直接下载。
iotop命令的键盘快捷键：
1、左右箭头改变排序方式，默认是按IO排序
2、r键是反向排序
3、o键是只显示有IO输出的进程
4、同样q是退出
选项：
--version 显示版本号然后退出
-h, --help 显示帮助然后退出
-o, --only 只显示正在产生I/O的进程或线程。除了传参，可以在运行过程中按o生效。
-b, --batch 非交互模式，一般用来记录日志
-n NUM, --iter=NUM 设置监测的次数，默认无限。在非交互模式下很有用
-d SEC, --delay=SEC 设置每次监测的间隔，默认1秒，接受非整形数据例如1.1
-p PID, --pid=PID 指定监测的进程/线程
-u USER, --user=USER 指定监测某个用户产生的I/O
-P, --processes 仅显示进程，默认iotop显示所有线程
-a, --accumulated 显示累积的I/O，而不是带宽
-k, --kilobytes 使用kB单位，而不是对人友好的单位。在非交互模式下，脚本编程有用。
-t, --time 加上时间戳，非交互非模式。
-q, --quiet 禁止头几行，非交互模式。有三种指定方式。
-q 只在第一次监测时显示列名
-qq 永远不显示列名。
-qqq 永远不显示I/O汇总。利用iotop排查过一个Ubuntu机器上由于mlocate这个cron任务引发的io利用率持续偏高的问题。 Ubuntu 可以禁用updatedb.mlocate吗？ 利用iotop排查过一个Ubuntu机器上由于mlocate这个cron任务引发的io利用率持续偏高的问题。
Ubuntu 可以禁用updatedb.mlocate吗？
htop
通俗来讲它就是一款查看器，即可以让用户与之交互的进程查看器；它主要用于主要用于控制台或 X 终端中。同时htop主要具有以下特性：可以定制、支持颜色主题以及按树状方式来查看进程；
除了以上三个之外，还有一个也是最常用的而且容易与以上三者进行混淆的即：atop。atop 是一个全屏的性能检测工具，主要是基于 ASCII ，其可以用来监控进程的活动时间，高亮显示出一些过载的进程，还包括其他的一些系统指标例如：CPU、内存、交换分区等。
参考文章：
iowait 过高问题的查找及解决linux
页:
[1]