一个依据 Linux 操作体系的效劳器运转的一起，也会表征出各式各样参数信息。一般来说运维人员、体系管理员会对这些数据会极为灵敏，可是这些参数关于开发者来说也十分重要，特别当你的程序非正常作业的时分，这些蛛丝马迹往往会协助快速定位盯梢问题。

这儿仅仅一些简略的东西检查体系的相关参数，当然许多东西也是经过剖析加工 /proc、/sys 下的数据来作业的，而那些愈加详尽、专业的功用监测和调优，可能还需求愈加专业的东西(perf、systemtap 等)和技能才干完结哦。

究竟来说，体系功用监控自身就是个大学识。

​

一、CPU和内存类

1.1 top



榜首行后边的三个值是体系在之前 1、5、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 运用率过高状况下指明晰相应地排查思路：

当 user 占用率过高的时分，一般是某些个其他进程占用了许多的 CPU，这时分很简略经过 top 找到该程序;此刻如果置疑程序反常，能够经过 perf 等思路找出热门调用函数来进一步排查;
当 system 占用率过高的时分，如果 IO 操作(包含终端 IO)比较多，可能会形成这部分的 CPU 占用率高，比方在 file server、database server 等类型的效劳器上，不然(比方>20%)很可能有些部分的内核、驱动模块有问题;
当 nice 占用率过高的时分，一般是有意行为，当进程的建议者知道某些进程占用较高的 CPU，会设置其 nice 值保证不会吞没其他进程对 CPU 的运用恳求;
当 iowait 占用率过高的时分，一般意味着某些程序的 IO 操作功率很低，或许 IO 对应设备的功用很低以至于读写操作需求很长的时刻来完结;
当 irq/softirq 占用率过高的时分，很可能某些外设呈现问题，导致发作许多的irq恳求，这时分经过检查 /proc/interrupts 文件来深究问题所在;
当 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： 闪现缺页过错和内存运用状况，缺页过错是程序需求拜访映射在虚拟内存空间中可是还尚未被加载到物理内存中的一个分页，缺页过错两个首要类型是

minflt/s 指的 minor faults，当需求拜访的物理页面因为某些原因(比方同享页面、缓存机制等)现已存在于物理内存中了，仅仅在当时进程的页表中没有引证，MMU 只需求设置对应的 entry 就能够了，这个价值是适当小的
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

二、磁盘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 技能，运用读写缓存技能来改进功用，不过这又跟上面的物理内存的约束相制约了。

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

三、网络类

网络功用关于效劳器的重要性显而易见，东西 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 敞开后对网卡和体系的功用会有影响，进而会影响到在线事务的功用。



本文完!