服务器病了吗？ Linux 服务器的那些性能参数指标

一个基于 Linux 操做系统的服务器运行的同时，也会表征出各类各样参数信息。一般来讲运维人员、系统管理员会对这些数据会极为敏感，可是这些参数对于开发者来讲也十分重要，尤为当你的程序非正常工做的时候，这些蛛丝马迹每每会帮助快速定位跟踪问题。

这里只是一些简单的工具查看系统的相关参数，固然不少工具也是经过分析加工 /proc、/sys 下的数据来工做的，而那些更加细致、专业的性能监测和调优，可能还须要更加专业的工具(perf、systemtap 等)和技术才能完成哦。毕竟来讲，系统性能监控自己就是个大学问。

1、CPU和内存类

1.1 top

➜ ~ top

第一行后面的三个值是系统在以前 一、五、15 的平均负载，也能够看出系统负载是上升、平稳、降低的趋势，当这个值超过 CPU 可执行单元的数目，则表示 CPU 的性能已经饱和成为瓶颈了。

第二行统计了系统的任务状态信息。running 很天然没必要多说，包括正在 CPU 上运行的和将要被调度运行的；sleeping 一般是等待事件(好比 IO 操做)完成的任务，细分能够包括 interruptible 和 uninterruptible 的类型；stopped 是一些被暂停的任务，一般发送 SIGSTOP 或者对一个前台任务操做 Ctrl-Z 能够将其暂停；zombie 僵尸任务，虽然进程终止资源会被自动回收，可是含有退出任务的 task descriptor 须要父进程访问后才能释放，这种进程显示为 defunct 状态，不管是由于父进程提早退出仍是未 wait 调用，出现这种进程都应该格外注意程序是否设计有误。 第三行 CPU 占用率根据类型有如下几种状况：

• (us) user：CPU 在低 nice 值(高优先级)用户态所占用的时间(nice<=0)。正常状况下只要服务器不是很闲，那么大部分的 CPU 时间应该都在此执行这类程序
• (sy) system：CPU 处于内核态所占用的时间，操做系统经过系统调用(system call)从用户态陷入内核态，以执行特定的服务；一般状况下该值会比较小，可是当服务器执行的 IO 比较密集的时候，该值会比较大
• (ni) nice：CPU 在高 nice 值(低优先级)用户态以低优先级运行占用的时间(nice>0)。默认新启动的进程 nice=0，是不会计入这里的，除非手动经过 renice 或者 setpriority() 的方式修改程序的nice值
• (id) idle：CPU 在空闲状态(执行 kernel idle handler )所占用的时间
• (wa) iowait：等待 IO 完成作占用的时间
• (hi) irq：系统处理硬件中断所消耗的时间
• (si) softirq：系统处理软中断所消耗的时间，记住软中断分为 softirqs、tasklets (实际上是前者的特例)、work queues，不知道这里是统计的是哪些的时间，毕竟 work queues 的执行已经不是中断上下文了
• (st) steal：在虚拟机状况下才有意义，由于虚拟机下 CPU 也是共享物理 CPU 的，因此这段时间代表虚拟机等待 hypervisor 调度 CPU 的时间，也意味着这段时间 hypervisor 将 CPU 调度给别的 CPU 执行，这个时段的 CPU 资源被“stolen”了。这个值在我 KVM 的 VPS 机器上是不为 0 的，但也只有 0.1 这个数量级，是否是能够用来判断 VPS 超售的状况？

CPU 占用率高不少状况下意味着一些东西，这也给服务器 CPU 使用率太高状况下指明了相应地排查思路：

1. 当 user 占用率太高的时候，一般是某些个别的进程占用了大量的 CPU，这时候很容易经过 top 找到该程序；此时若是怀疑程序异常，能够经过 perf 等思路找出热点调用函数来进一步排查；
2. 当 system 占用率太高的时候，若是 IO 操做(包括终端 IO)比较多，可能会形成这部分的 CPU 占用率高，好比在 file server、database server 等类型的服务器上，不然(好比>20%)极可能有些部分的内核、驱动模块有问题；
3. 当 nice 占用率太高的时候，一般是有意行为，当进程的发起者知道某些进程占用较高的 CPU，会设置其 nice 值确保不会淹没其余进程对 CPU 的使用请求；
4. 当 iowait 占用率太高的时候，一般意味着某些程序的 IO 操做效率很低，或者 IO 对应设备的性能很低以致于读写操做须要很长的时间来完成；
5. 当 irq/softirq 占用率太高的时候，极可能某些外设出现问题，致使产生大量的irq请求，这时候经过检查 /proc/interrupts 文件来深究问题所在；
6. 当 steal 占用率太高的时候，黑心厂商虚拟机超售了吧！

第四行和第五行是物理内存和虚拟内存(交换分区)的信息： total = free + used + buff/cache，如今buffers和cached Mem信息总和到一块儿了，可是buffers和cached

Mem 的关系不少地方都没说清楚。其实经过对比数据，这两个值就是 /proc/meminfo 中的 Buffers 和 Cached 字段：Buffers 是针对 raw disk 的块缓存，主要是以 raw block 的方式缓存文件系统的元数据(好比超级块信息等)，这个值通常比较小(20M左右)；而 Cached 是针对于某些具体的文件进行读缓存，以增长文件的访问效率而使用的，能够说是用于文件系统中文件缓存使用。

而 avail Mem 是一个新的参数值，用于指示在不进行交换的状况下，能够给新开启的程序多少内存空间，大体和 free + buff/cached 至关，而这也印证了上面的说法，free + buffers + cached Mem才是真正可用的物理内存。而且，使用交换分区不见得是坏事情，因此交换分区使用率不是什么严重的参数，可是频繁的 swap in/out 就不是好事情了，这种状况须要注意，一般表示物理内存紧缺的状况。

最后是每一个程序的资源占用列表，其中 CPU 的使用率是全部 CPU core 占用率的总和。一般执行 top 的时候，自己该程序会大量的读取 /proc 操做，因此基本该 top 程序自己也会是名列前茅的。

top 虽然很是强大，可是一般用于控制台实时监测系统信息，不适合长时间(几天、几个月)监测系统的负载信息，同时对于短命的进程也会遗漏没法给出统计信息。

1.2 vmstat

vmstat 是除 top 以外另外一个经常使用的系统检测工具，下面截图是我用-j4编译boost的系统负载。

r 表示可运行进程数目，数据大体相符；而b表示的是 uninterruptible 睡眠的进程数目；swpd 表示使用到的虚拟内存数量，跟 top-Swap-used 的数值是一个含义，而如手册所说，一般状况下 buffers 数目要比 cached Mem 小的多，buffers 通常20M这么个数量级；io 域的 bi、bo 代表每秒钟向磁盘接收和发送的块数目(blocks/s)；system 域的 in 代表每秒钟的系统中断数(包括时钟中断)，cs代表由于进程切换致使上下文切换的数目。

说到这里，想到之前不少人纠结编译 linux kernel 的时候 -j 参数到底是 CPU Core 仍是 CPU Core+1？经过上面修改 -j 参数值编译 boost 和 linux kernel 的同时开启 vmstat 监控，发现两种状况下 context switch 基本没有变化，且也只有显著增长 -j 值后 context switch 才会有显著的增长，看来没必要过于纠结这个参数了，虽然具体编译时间长度我尚未测试。资料说若是不是在系统启动或者 benchmark 的状态，参数 context switch>100000 程序确定有问题。

1.3 pidstat

若是想对某个进程进行全面具体的追踪，没有什么比 pidstat 更合适的了——栈空间、缺页状况、主被动切换等信息一览无余。这个命令最有用的参数是-t，能够将进程中各个线程的详细信息罗列出来。

-r： 显示缺页错误和内存使用情况，缺页错误是程序须要访问映射在虚拟内存空间中可是还还没有被加载到物理内存中的一个分页，缺页错误两个主要类型是

1. minflt/s 指的 minor faults，当须要访问的物理页面由于某些缘由(好比共享页面、缓存机制等)已经存在于物理内存中了，只是在当前进程的页表中没有引用，MMU 只须要设置对应的 entry 就能够了，这个代价是至关小的
2. majflt/s 指的 major faults，MMU 须要在当前可用物理内存中申请一块空闲的物理页面(若是没有可用的空闲页面，则须要将别的物理页面切换到交换空间去以释放获得空闲物理页面)，而后从外部加载数据到该物理页面中，并设置好对应的 entry，这个代价是至关高的，和前者有几个数据级的差别

-s：栈使用情况，包括 StkSize 为线程保留的栈空间，以及 StkRef 实际使用的栈空间。使用ulimit -s发现CentOS 6.x上面默认栈空间是10240K，而 CentOS 7.x、Ubuntu系列默认栈空间大小为8196K

-u：CPU使用率状况，参数同前面相似

-w：线程上下文切换的数目，还细分为cswch/s由于等待资源等因素致使的主动切换，以及nvcswch/s线程CPU时间致使的被动切换的统计

若是每次都先ps获得程序的pid后再操做pidstat会显得很麻烦，因此这个杀手锏的-C能够指定某个字符串，而后Command中若是包含这个字符串，那么该程序的信息就会被打印统计出来，-l能够显示完整的程序名和参数 ➜ ~ pidstat -w -t -C “ailaw” -l

这么看来，若是查看单个尤为是多线程的任务时候，pidstat比经常使用的ps更好使！

1.4 其余

当须要单独监测单个 CPU 状况的时候，除了 htop 还可使用 mpstat，查看在 SMP 处理器上各个 Core 的工做量是否负载均衡，是否有某些热点线程占用 Core。 ➜ ~ mpstat -P ALL 1

若是想直接监测某个进程占用的资源，既可使用top -u taozj的方式过滤掉其余用户无关进程，也能够采用下面的方式进行选择，ps命令能够自定义须要打印的条目信息：

while :; do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd'; sleep 1; done

如想理清继承关系，下面一个经常使用的参数能够用于显示进程树结构，显示效果比pstree详细美观的多

➜ ~ ps axjf

2、磁盘IO类

iotop 能够直观的显示各个进程、线程的磁盘读取实时速率；lsof 不只能够显示普通文件的打开信息(使用者)，还能够操做 /dev/sda1 这类设备文件的打开信息，那么好比当分区没法 umount 的时候，就能够经过 lsof 找出磁盘该分区的使用状态了，并且添加 +fg 参数还能够额外显示文件打开 flag 标记。

2.1 iostat

➜ ~ iostat -xz 1

其实不管使用 iostat -xz 1 仍是使用 sar -d 1，对于磁盘重要的参数是：

• avgqu-s：发送给设备 I/O 请求的等待队列平均长度，对于单个磁盘若是值>1代表设备饱和，对于多个磁盘阵列的逻辑磁盘状况除外
• await(r_await、w_await)：平均每次设备 I/O 请求操做的等待时间(ms)，包含请求排列在队列中和被服务的时间之和；
• svctm：发送给设备 I/O 请求的平均服务时间(ms)，若是 svctm 与 await 很接近，表示几乎没有 I/O 等待，磁盘性能很好，不然磁盘队列等待时间较长，磁盘响应较差；
• %util：设备的使用率，代表每秒中用于 I/O 工做时间的占比，单个磁盘当 %util>60% 的时候性能就会降低(体如今 await 也会增长)，当接近100%时候就设备饱和了，但对于有多个磁盘阵列的逻辑磁盘状况除外；

还有，虽然监测到的磁盘性能比较差，可是不必定会对应用程序的响应形成影响，内核一般使用 I/O asynchronously 技术，使用读写缓存技术来改善性能，不过这又跟上面的物理内存的限制相制约了。

上面的这些参数，对网络文件系统也是受用的。

3、网络类

网络性能对于服务器的重要性不言而喻，工具 iptraf 能够直观的现实网卡的收发速度信息，比较的简洁方便经过 sar -n DEV 1 也能够获得相似的吞吐量信息，而网卡都标配了最大速率信息，好比百兆网卡千兆网卡，很容易查看设备的利用率。

一般，网卡的传输速率并非网络开发中最为关切的，而是针对特定的 UDP、TCP 链接的丢包率、重传率，以及网络延时等信息。

3.1 netstat

➜ ~ netstat -s

显示自从系统启动以来，各个协议的整体数据信息。虽然参数信息比较丰富有用，可是累计值，除非两次运行作差才能得出当前系统的网络状态信息，亦或者使用 watch 眼睛直观其数值变化趋势。因此netstat一般用来检测端口和链接信息的：

netstat –all(a) –numeric(n) –tcp(t) –udp(u) –timers(o) –listening(l) –program(p)

–timers能够取消域名反向查询，加快显示速度；比较经常使用的有

➜ ~ netstat -antp #列出全部TCP的链接

➜ ~ netstat -nltp #列出本地全部TCP侦听套接字，不要加-a参数

3.2 sar

sar 这个工具太强大了，什么 CPU、磁盘、页面交换啥都管，这里使用 -n 主要用来分析网络活动，虽然网络中它还给细分了 NFS、IP、ICMP、SOCK 等各类层次各类协议的数据信息，咱们只关心 TCP 和 UDP。下面的命令除了显示常规状况下段、数据报的收发状况，还包括

TCP ➜ ~ sudo sar -n TCP,ETCP 1

• active/s：本地发起的 TCP 链接，好比经过 connect()，TCP 的状态从CLOSED -> SYN-SENT
• passive/s：由远程发起的 TCP 链接，好比经过 accept()，TCP 的状态从LISTEN -> SYN-RCVD
• retrans/s(tcpRetransSegs)：每秒钟 TCP 重传数目，一般在网络质量差，或者服务器过载后丢包的状况下，根据 TCP 的确认重传机制会发生重传操做
• isegerr/s(tcpInErrs)：每秒钟接收到出错的数据包(好比 checksum 失败)

UDP ➜ ~ sudo sar -n UDP 1

• noport/s(udpNoPorts)：每秒钟接收到的可是却没有应用程序在指定目的端口的数据报个数
• idgmerr/s(udpInErrors)：除了上面缘由以外的本机接收到但却没法派发的数据报个数

固然，这些数据必定程度上能够说明网络可靠性，但也只有同具体的业务需求场景结合起来才具备意义。

3.3 tcpdump

tcpdump 不得不说是个好东西。你们都知道本地调试的时候喜欢使用 wireshark，可是线上服务端出现问题怎么弄呢？

附录的参考文献给出了思路：复原环境，使用 tcpdump 进行抓包，当问题复现(好比日志显示或者某个状态显现)的时候，就能够结束抓包了，并且 tcpdump 自己带有 -C/-W 参数，能够限制抓取包存储文件的大小，当达到这个这个限制的时候保存的包数据自动 rotate，因此抓包数量整体仍是可控的。此后将数据包拿下线来，用 wireshark 想怎么看就怎么看，岂不乐哉！tcpdump 虽然没有 GUI 界面，可是抓包的功能丝绝不弱，能够指定网卡、主机、端口、协议等各项过滤参数，抓下来的包完整又带有时间戳，因此线上程序的数据包分析也能够这么简单。

下面就是一个小的测试，可见 Chrome 启动时候自动向 Webserver 发起创建了三条链接，因为这里限制了 dst port 参数，因此服务端的应答包被过滤掉了，拿下来用 wireshark 打开，SYNC、ACK 创建链接的过程仍是很明显的！在使用 tcpdump 的时候，须要尽量的配置抓取的过滤条件，一方面便于接下来的分析，二则 tcpdump 开启后对网卡和系统的性能会有影响，进而会影响到在线业务的性能。