基于Linux操作系统的服务器运行的一些蛛丝马迹

基于Linux操作系统的服务器在运行时，会显示各种参数信息。 这些线索往往有助于快速定位跟踪问题。

这里只是提供一些简单的工具来查看系统的相关参数。 当然，很多工具也是通过分析和处理/proc和/sys下的数据来工作的。 那些更细致、更专业的性能监控和调优可能需要更专业的工具（perf等）和技术才能完成。 毕竟，系统性能监控本身就是一门大学学科。

1. CPU和内存等级1.1顶级

➜~顶

第一行之后的三个值分别是系统前1年、5年、15年的平均负载。 还可以看出系统负载有上升、稳定、下降的趋势。 当这个值超过CPU可执行单元的数量时，就意味着CPU的性能已经饱和，已经成为瓶颈。

第二行统计系统的任务状态信息。 自然不用说，包括在CPU上运行的和将被调度运行的； 通常是等待事件（如IO操作）完成的任务，细分可以包括 和 类型； 一些挂起的任务，通常发送或者在前台任务上操作Ctrl-Z可以挂起它； 对于僵尸任务，虽然进程终止时资源会自动回收，但包含退出任务的任务需要被父进程访问后才能被释放。 这种进程显示为状态，不管是否是因为父进程的原因。 进程是否提前退出或者没有调用wait，如果出现这样的过程，要特别注意程序设计是否有误。

第三行CPU使用率根据类型有以下几种情况：

√ (us) user：CPU在低nice值（高优先级）用户模式（nice0）所花费的时间。默认情况下，新启动的进程nice=0，这里不会包含，除非nice值通过或（）手动修改程序。

√ (id)idle：CPU处于idle状态（执行idle）所花费的时间

√ (wa): 等待IO完成所花费的时间

√ (hi)irq：系统处理硬件中断所花费的时间

√(si)：系统处理软中断所花费的时间。 请记住，软中断分为（实际上是前者的特例）和工作。 我不知道这里算什么时间。 毕竟，工作的执行不再是中断上下文。 知道了

√ (st) 窃取：仅在虚拟机的情况下才有意义。 因为虚拟机下的CPU也共享物理CPU，所以这段时间表示虚拟机等待CPU被调度的时间。 也意味着这段时间CPU被调度给了别人。 CPU执行时，这段时间的CPU资源是“”。 在我的KVM VPS机器上这个值不是0，但它只是0.1的量级。 可以用来判断VPS是否超额预订吗？

CPU占用率高往往意味着什么，这也提供了服务器CPU占用率过高时相应的排查思路：

√ 当用户占用率过高时，通常是某些个别进程占用大量CPU。 这时候通过top就很容易找到程序了； 如果怀疑程序异常，可以通过perf等思路找到热调用函数。 进一步调查；

√ 占用率过高时，如果IO操作较多（包括终端IO），这部分CPU占用率可能会很高，比如on file等类型的服务器，否则（比如>20 %) 很可能是内核和驱动模块的某些部分存在问题；

√ 当nice入住率过高时，通常是一种故意行为。 当进程的发起者知道某些进程占用较高的CPU时，它会设置其nice值，以确保不会淹没其他进程的CPU使用请求；

√ 当占用率过高时，通常意味着某些程序的IO操作效率很低，或者IO对应设备的性能太低，导致读写操作需要很长时间才能完成；

√ 当irq/占用率过高时，很可能是部分外设出现问题，导致大量irq请求。 这时检查/proc/文件即可找出问题所在；

√ 当盗用占用率太高时，无良厂家的虚拟机已经超卖了！

第四行和第五行是物理内存和虚拟内存（交换分区）的信息：

Total = free +used + buff/cache，现在和Mem的total信息合并了，但是很多地方和Mem的关系不太清楚。 其实通过对比数据，这两个值就是/proc/中的 和 字段：是裸盘的块缓存。 它主要以raw block的形式缓存文件系统的元数据（如超级块信息等）。 这个值一般比较小（20M左右）； 用于某些特定文件的读缓存，以提高文件访问效率。 可以说是用于文件系统中的文件缓存。

而avail Mem是一个新的参数值，用来表示在不交换的情况下可以给新打开的程序多少内存空间，大致相当于free + buff/，而这也印证了上面的说法，free + + Mem是实际可用的物理内存。 而且，使用交换分区并不一定是坏事，因此交换分区使用率并不是一个严重的参数，但频繁的换入/换出却并不是一件好事。 这种情况需要引起注意，通常表明物理内存不足。

最后是每个程序的资源使用情况列表，其中CPU使用情况是所有CPU核心的使用情况之和。 通常top执行的时候，程序本身会读取大量的/proc操作，所以基本上top程序本身会名列前茅。

虽然top功能很强大，但通常用于在控制台实时监控系统信息。 不适合长时间（数天或数月）监控系统负载信息。 同时，短暂的进程也会被遗漏，无法提供统计信息。

1.2

它是除了top之外的另一个常用的系统检测工具。 下面的截图是我用-j4编译boost时的系统负载。

r表示可运行进程数，数据大致一致； b表示休眠进程数； swpd 代表虚拟内存使用量，与 top-Swap-used 的值含义相同，并且如手册所说，通常该数字比 Mem 小很多，一般为 20M 量级； io域的bi和bo表示每秒接收并发送到磁盘的块数（/s）； in域表示每秒系统中断次数（包括时钟中断），cs表示进程切换引起的上下文切换次数。

说到这里，我想到了以前很多人在编译Linux时纠结于-j参数到底应该是CPU Core还是CPU Core+1。 通过修改上面的-j参数值，同时编译boost和linux并开启监控，我们发现两种情况基本没有变化，只有大幅增加-j值后才有明显的提升。 看来这个参数不用太担心。 虽然具体的编译时间长度我没有测试过。 资料上说，如果不是在系统启动或者状态下，肯定是参数>程序有问题。

1.3

如果你想对某个进程进行全面细致的跟踪，没有比这更合适的了——堆栈空间、缺页情况、主动被动切换等信息一目了然。 该命令最有用的参数是-t，它可以列出进程中每个线程的详细信息。

-r：显示页面错误和内存使用情况。 页面错误是指程序需要访问映射到虚拟内存空间但尚未加载到物理内存中的页面。 页面错误的两种主要类型是

√ /s 表示小调。 当需要访问的物理页由于某种原因（如共享页、缓存机制等）已经存在于物理内存中，但在当前进程的页表中没有被引用时，MMU只需要设置对应的Entry就够了，价格也相当小

√ /s 指major，MMU需要在当前可用物理内存中申请一个空闲物理页（如​​果没有空闲页可用，需要将其他物理页切换到交换空间来释放空闲物理页），然后从外部加载数据到物理页并设置相应的条目。 这个成本相当高，而且和前者有几个数据层面的差异。

-s：堆栈使用情况，包括为线程保留的堆栈空间和实际使用的堆栈空间。 使用-s发现6.x上默认堆栈空间大小为8196K，而7.x及系列默认堆栈空间大小为8196K

-u：CPU使用率，参数与前面类似

-w：线程上下文切换次数，同样细分为因等待资源等因素引起的cswch/s主动切换和线程CPU时间引起的/s被动切换统计。

如果每次操作之前先ps获取程序的pid的话会很麻烦，所以这个杀手锏-C可以指定某个字符串，然后如果包含这个字符串，那么就会打印并统计程序信息。 , -l 可以显示完整的程序名和参数

➜ ~ -w -t -C “ailaw” -l

从这一点来看，如果从单线程，尤其是多线程任务来看，比常用的PS要好！

1.4 其他

当需要单独监控单个CPU的情况时，还可以使用htop来检查SMP处理器上各个Core的工作负载是否负载均衡，以及是否有一些热点线程占用了Core。

➜ ~ -P 全部 1

如果想直接监控某个进程占用的资源，可以使用top -u taozj过滤掉其他与用户无关的进程，也可以使用下面的方法进行选择。 ps命令可以自定义需要打印的条目信息：

尽管 ：; 执行 ps -eo 用户、pid、ni、pri、pcpu、psr、comm | grep ''; 睡觉1； 完毕

如果想明确继承关系，可以使用以下常用参数来显示流程树结构。 显示效果更加细致、美观。

➜~ps axjf

2.磁盘IO类

iotop可以直观地显示各个进程和线程的实时磁盘读取速率； lsof不仅可以显示普通文件（用户）的打开信息，还可以操作/dev/sda1等设备文件的打开信息，所以比如当分区不能时，可以使用lsof来了解使用情况磁盘分区的信息，加上+fg参数还可以额外显示文件打开标志标记。

2.1

➜~-xz 1

事实上，无论你使用-xz 1还是sar -d 1，磁盘的重要参数是：

√ avgqu-s：发送到设备的 I/O 请求的等待队列的平均长度。 对于单个磁盘，值>1表示设备已饱和，但具有多个磁盘阵列的逻辑磁盘除外。

√await(,)：每次设备I/O请求操作的平均等待时间（ms），包括请求排队和服务的时间总和；

√ svctm：发送到设备的 I/O 请求的平均服务时间（ms）。 如果svctm非常接近await，则说明几乎没有I/O等待，磁盘性能非常好。 否则，磁盘队列等待时间长，磁盘响应差。 ;

√ %util：设备的使用率，表示每秒I/O工作时间的比例。 当%util>60%时，单个磁盘的性能会下降（体现在await的增加）。 当接近100%的时候，设备就饱和了，多磁盘阵列的逻辑磁盘除外；

另外，虽然监控到的磁盘性能比较差，但并不一定会影响应用程序的响应。 内核通常会使用I/O技术和读写缓存技术来提高性能，但这与上面的物理内存不同。 受限制的。

上述参数也适用于网络文件系统。

3、网络类

网络性能对于服务器的重要性不言而喻。 该工具可以直观地显示网卡的发送和接收速度信息。 比较简单方便。 通过 sar -n DEV 1 也可以获得类似的吞吐量信息，并且网卡标配了最大速度。 100M网卡、千兆网卡等信息，方便查看设备的利用率。

通常，网络开发中最关心的并不是网卡的传输速率，而是特定UDP和TCP连接的丢包率、重传率、网络延迟等信息。

3.1

➜~-s

显示系统启动以来各协议的总体数据信息。 虽然参数信息比较丰富且有用，但必须利用两次运行的差值来获取当前系统的网络状态信息，或者可以使用手表来可视化数值变化趋势，才能获得累积值。 所以通常用来检测端口和连接信息：

–全部(a) –(n) –tcp(t) –udp(u) –(o) –(l) –(p)

– 可以取消域名反向查询，加快显示速度； 更常用的是

➜ ~ -antp #列出所有TCP连接

➜ ~ -nltp #列出所有本地TCP监听套接字，不加-a参数

3.2SAR

sar是一个非常强大的工具。 它可以控制从CPU、磁盘到页面交换的一切。 这里使用的-n主要用于分析网络活动。 虽然网络也细分为NFS、IP、ICMP、SOCK等各种级别，但对于各种协议的数据信息，我们只关心TCP和UDP。除了显示下报文段和数据报的发送和接收状态一般情况下，还包括以下命令

传输控制协议

➜ ~ sudo sar -n TCP,ETCP 1

√ /s：本地发起的TCP连接，如通过()，TCP状态从->SYN-SENT转变

√ /s：远程发起TCP连接，如通过()，TCP状态由->SYN-RCVD变化

√ /s()：每秒TCP重传次数。 通常当网络质量较差或者服务器过载而丢包时，会根据TCP确认重传机制发生重传操作。

√ /s()：每秒收到错误数据包（如失败）

UDP协议

➜ ~ sudo sar -n UDP 1

√ /s(): 指定目的端口上没有应用程序的情况下每秒接收的数据报数

√ /s(): 除上述原因外，本机已收到但无法投递的数据报数量。

当然，这些数据可以在一定程度上说明网络的可靠性，但只有结合具体的业务需求场景才有意义。

3.3

我不得不说这是一件好事。 大家都知道本地调试的时候喜欢用它，但是如果线上服务器出现问题怎么办呢？

附录中的参考资料给出了一个思路：恢复环境，用它来抓包，当问题再次出现时（比如日志显示或者出现某种状态），可以结束抓包，它有-C/- W 参数可以限制抓包存储文件的大小。 当达到这个限制时，保存的数据包数据会自动保存，因此捕获的数据包总数是可控的。 之后，您可以将数据包离线并随心所欲地观看。 这不是很有趣吗？ 虽然没有GUI界面，但是抓包功能一点也不弱。 您可以指定网卡、主机、端口、协议等过滤参数。 捕获的数据包完整且有时间戳，因此也可以进行在线程序的数据包分析。 很简单。

下面是一个小测试。 可以看到启动时自动与发起者建立了3个连接。 由于这里限制了dst端口参数，所以服务器的响应包被过滤掉了。 把它们拿下来并打开后，与SYNC和ACK建立连接的过程仍然很长。 明显地！ 使用时需要尽可能配置捕获过滤条件。 一方面方便后续分析。 另一方面，开启会对网卡和系统的性能产生影响，进而影响线上业务的性能。