linux服务器性能分析只需1分钟

背景:

现在的互联网公司,大多数时候应用服务都是部署在linux服务器上,那么当你的服务运行过程中出现了一些响应慢,资源瓶颈等疑似性能问题时,给你60秒,如何快速完成初步检测?

肯定有人会说用工具,公司全链路监控系统(pinpoint,skywalking,danatrace等),以及各种其他监控分析工具(cat,arthas,jaeger,jprofiler,mat等),这些工具可以帮助我们解决大多数问题,但是前提得有,因此有些时候我们不得不还是需要登录linux实例机器并运行一些标准的Linux性能工具进行快速分析。

前言:

在本文中,由Netflix Performance Engineering团队总结展示了使用标准Linux命令行工具,在最初的60秒内应该进行的性能分析监测。在60秒内,通过运行以下十个命令来全面了解linux系统资源的使用和运行进程。寻找错误和资源瓶颈指标,因为使用它们既易于解释,又不太占用系统本身资源。

60秒巡检10步曲:

1.uptime命令

检测这台服务器活了多久,以及它的平均负载是多少。

它是唯一快捷的查看系统负载的方式,load average这3个数值是以递减的方式统计了过去 1 分钟,5 分钟和 15 分钟系统负载的变化过程。

 2.dmesg -T |tail 

检测linux系统日志里面有没有异常错误日志,查找可能导致性能问题的系统错误。

 3.vmstat 1

监测系统虚拟内存的状态,页的换进换出有没有问题,swap有没有触发使用。

每列含义说明:

  1. r: CPU 上的等待运行的可运行进程数。这个指标提供了判断 CPU 饱和度的数据,因为它不包含 I/O 等待的进程。可解释为:“r” 的值比 CPU 数大的时候就是饱和的。

  2. free:空闲内存,单位是 k。如果这个数比较大,就说明你还有充足的空闲内存。“free -m” 和下面第 7 个命令,可以更详细的分析空闲内存的状态。

  3. si,so:交换进来和交换出去的数据量,如果这两个值为非 0 值,那么就说明没有内存了。

  4. us,sy,id,wa,st:这些是 CPU 时间的分解,是所有 CPU 的平均值。它们是用户时间,系统时间(内核),空闲,等待 I/O 时间,和被偷的时间(这里主要指其它的客户,或者使用 Xen,这些客户有自己独立的操作域)。

CPU 时间的分解可以帮助确定 CPU 是不是非常忙(通过用户时间和系统时间累加判断)。持续的 I/O 等待则表明磁盘是瓶颈。这种情况下 CPU 是比较空闲的,因为任务都由于等待磁盘 I/O 而被阻塞。你可以把等待 I/O 看作是另外一种形式的 CPU 空闲,而这个命令给了为什么它们空闲的线索。

系统时间对于 I/O 处理来说是必须的。比较高的平均系统时间消耗,比如超过了 20%,就有必要进一步探索分析了:也有可能是内核处理 I/O 效率不够高导致。

当系统的cpu的使用率大于90%时,不一定有问题,可以使用 “r” 列来检查使用饱和度。

4.mpstat -P ALL 1

检测linux服务器CPU压力在每个核上是否分布均匀。

 5.pidstat 1

监测linux服务器上各个进程对资源占用大概是什么样子。

它是以不断滚动更新的方式打印信息,而不是每次清屏打印。这个对于观察随时间变化的模式很有用,方便把看到的信息记录(复制粘贴)到调查记录中。

 6.iostat -xz 1

检查块设备,磁盘IO问题,看是否有IO瓶颈。

每列含义说明:

  1. r/s, w/s, rkB/s, wkB/s:这些表示设备上每秒钟的读写次数和读写的字节数(单位是k字节)。这些可以看出设备的负载情况。性能问题可能就是简单的因为大量的文件加载请求。

  2. await:I/O 等待的平均时间(单位是毫秒)。这是应用程序所等待的时间,包含了等待队列中的时间和被调度服务的时间。过大的平均等待时间就预示着设备超负荷了或者说设备有问题了。

  3. avgqu-sz:设备上请求的平均数。数值大于 1 可能表示设备饱和了(虽然设备通常都是可以支持并行请求的,特别是在背后挂了多个磁盘的虚拟设备)。

  4. %util:设备利用率。是使用率的百分数,展示每秒钟设备工作的时间。这个数值大于 60% 则会导致性能很低(可以在 await 中看),当然这也取决于设备特点。这个数值接近 100% 则表示设备饱和了。

如果存储设备是一个逻辑磁盘设备,后面挂载了多个磁盘,那么 100% 的利用率则只是表示有些 I/O 是在 100% 处理,然而后端的磁盘或许远远没有饱和,还可以处理更多的请求。

请记住,磁盘 I/O 性能低不一定是应用程序的问题。许多技术通常都被用来实现异步执行 I/O,所以应用程序不会直接阻塞和承受延时(比如:预读取和写缓冲技术)。

7.free -m

查看系统内存使用率,是否有内存资源饱和。

每列含义说明:

  1. buffers:用于块设备 I/O 缓冲的缓存。

  2. cached:用于文件系统的页缓存。

检测这些缓存的数值是否接近 0 。不为 0 的可能导致较高的磁盘 I/O(通过 iostat 命令来确认)和较差的性能问题。

“-/+ buffers/cache” 这一行提供了对已使用和空闲内存明确的统计。Linux 用空闲内存作为缓存,如果应用程序需要,可以快速拿回去。所以应该包含空闲内存那一列,这里就是这么统计的。

如果在 Linux 上使用了 ZFS 文件系统,则可能会更乱,因为当我们在开发一些服务的时候,ZFS 有它自己的文件系统缓存,而这部分内存的消耗是不会在 free -m 这个命令中合理的反映的。显示了系统内存不足,但是 ZFS 的这部分缓存是可以被应用程序使用的。

8.sar -n DEV 1

检测网络接口的吞吐量,是否达到收发极限。

rxkB/s 和 txkB/s,作为网络收发数据负载的度量,也是检测是否达到收发极限。(1M 字节/秒等于1024kB/s,也就是 8 Mbit/秒(网卡的上限是 1 Gbit/秒)。 

9.sar -n TCP,ETCP 1

监测网络的消耗状态,TCP的连接速率,重传,错误率等信息。

每列含义说明:

  1. active/s:每秒本地发起的 TCP 连接数(例如通过 connect() 发起的连接)。

  2. passive/s:每秒远程发起的连接数(例如通过 accept() 接受的连接)。

  3. retrans/s:每秒TCP重传数。

这种主动和被动统计数通常用作对系统负载的粗略估计:新接受连接数(被动),下游连接数(主动)。可以把主动看作是外部的,被动的是内部,但是这个通常也不是非常准确(例如:当有本地到本地的连接时)。

重传是网络或者服务器有问题的一个信号;可能是一个不可靠的网络(例如:公网),或者可能是因为服务器过载了开始丢包。

10.top

监测一下大致的进程和线程问题。

 top 的一个缺陷也比较明显,很难看出变化趋势,其它像 vmstat 和 pidstat 这样的工具就会很清晰,它们是以滚动的方式输出统计信息。所以如果你在看到有问题的信息时没有及时的暂停下来(Ctrl-S 是暂停, Ctrl-Q 是继续),那么这些有用的信息就会被清屏。

原文:https://netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55

原文地址:https://www.cnblogs.com/johnny-chen/p/13529709.html