阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

如何快速分析出现性能问题的Linux服务器

244次阅读
没有评论

共计 8569 个字符,预计需要花费 22 分钟才能阅读完成。

本文将详细介绍以下这些 Linux 命令及其扩展选项的意义,及其在实践中的作用。并利用一个实际出现问题的例子,来验证这些套路是不是可行,下面工具的屏幕输出结果都来自这个出现问题的系统。当遇到一个系统性能问题时,如何利用登录的前 60 秒对系统的性能情况做一个快速浏览和分析,主要包括如下 10 个工具,这是一个非常有用且有效的工具列表。

# 系统负载概览
uptime

# 系统日志
dmesg | tail

# CPU
vmstat 1
mpstat -P ALL 1
pidstat 1

# Disk
iostat -xz 1

# 内存
free -m

# 网络
sar -n DEV 1
sar -n TCP,ETCP 1

# 系统概览
top

上面的工具都基于 内核提供给用户态的统计,并以计数器形式展示,是快速排查时的利器。对于应用和系统的进一步跟踪(tracing),则需要利用 strace 和 systemtap 等工具,不在本文的范畴。

注意:

  • 如上基于 CPU, 内存,I/O,网络等的分类只是基于工具默认选项的分类,比如 pidstat,默认展示进程的 CPU 统计,但是利用 - d 参数可以展示进程的 I / O 统计。又比如 vmstat,虽然名称是查看虚拟内存的工具,但默认展示了负载,内存,I/O,系统,CPU 等多方面的信息。
  • 部分工具需要安装 sysstat 包。

1. uptime

[root@nginx1 ~]# uptime
 15:38:10 up 43 days,  3:54,  1 user,  load average: 1.13, 0.41, 0.18

uptime 是快速查看 load average 的方法,在 Linux 中 load average 包括处于 runnable 和 uninterruptable 状态的进程总数,runnable 状态包括在 CPU 上运行的进程和在 run queue 里 waiting for run time 等待 CPU 的进程;uninterruptable 状态的进程是在等待一些 I / O 访问,比如等待 disk 的返回。Load average 没有根据系统的 CPU 数量做格式化,所以 load average 1 表示单 CPU 系统在对应时间段内(1 分钟, 5 分钟, 15 分钟) 一直负载饱和,而在 4 CPU 的系统中,load average 1 表示有 75% 的时间在 idle。

Load average 体现了一个 high level 的负载概览,但是可能需要和别的工具一起来使用以了解更多信息 ,比如处于 runable 和 uninterruptable 的实时进程数量分别是多少,可以用下面将介绍到的 vmstat 来查看。1 分钟,5 分钟,15 分钟的负载平均值同时能 体现系统负载的变化情况。例如,如果你要检查一个问题服务器,当你看到 1 分钟的平均负载值已经远小于 15 分钟的平均负载值,则意味这也许你登录晚了点,错过了现场。用 top 或者 w 命令,也可以看到 load average 信息。

上面示例中最近 1 分钟内的负载比 15 分钟内的负载高了不少 (因为是个测试的例子,1.13 可以看作明显大于 0.18,但是在生产系统上这不能说明什么)。

2. dmesg | tail

[root@nginx1 ~]# dmesg | tail
[3128052.929139] device eth0 left promiscuous mode
[3128104.794514] device eth0 entered promiscuous mode
[3128526.750271] device eth0 left promiscuous mode
[3537292.096991] device eth0 entered promiscuous mode
[3537295.941952] device eth0 left promiscuous mode
[3537306.450497] device eth0 entered promiscuous mode
[3537307.884028] device eth0 left promiscuous mode
[3668025.020351] bash (8290): drop_caches: 1
[3674191.126305] bash (8290): drop_caches: 2
[3675304.139734] bash (8290): drop_caches: 1

dmesg 用于查看内核缓冲区存放的系统信息。另外查看 /var/log/messages 也可能查看出服务器系统方面的某些问题。

上面示例中的 dmesg 没有特别的值得注意的错误。

3. vmstat 1

如何快速分析出现性能问题的 Linux 服务器 

vmstat 简介:

  • vmstat 是 virtual memory stat 的简写,能够打印 processes, memory, paging, block IO, traps, disks and cpu 的相关信息。
  • vmstat 的格式:vmstat [options] [delay [count]]。在输入中的 1 是延迟。第一行打印的是机器启动到现在的平均值,后面打印的则是根据 deley 间隔的取样结果,也就是实时的结果。

结果中列的含义:

Procs(进程)

r: The number of runnable processes (running or waiting for run time).
b: The number of processes in uninterruptible sleep.

注释: r 表示在 CPU 上运行的进程和 ready 等待运行的进程总数,相比 load average, 这个值更能判断 CPU 是否饱和(saturation),因为它没有包括 I /O。如果 r 的值大于 CPU 数目,即达到饱和。

Memory

swpd: the amount of virtual memory used.
free: the amount of idle memory.
buff: the amount of memory used as buffers.
cache: the amount of memory used as cache.

Swap

si: Amount of memory swapped in from disk (/s).
so: Amount of memory swapped to disk (/s).

注释:swap-in 和 swap-out 的内存。如果是非零,说明主存中的内存耗尽。

IO

bi: Blocks received from a block device (blocks/s).
bo: Blocks sent to a block device (blocks/s).

System (中断和进程上下文切换)

in: The number of interrupts per second, including the clock.
cs: The number of context switches per second.

CPU

These are percentages of total CPU time.
us: Time spent running non-kernel code. (user time, including nice time)
sy: Time spent running kernel code. (system time)
id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.
wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle.
st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown.

根据 user+system 时间,可以判断 CPUs 是否繁忙。如果 wait I/ O 一直维持一定程度,说明 disk 有瓶颈,这时 CPUs 是 ”idle” 的,因为任务都被 block 在等待 disk I/ O 中。wait I/ O 可以被视为另一种形式的 CPU idle,并且说明 idle 的原因就是在等待 disk I/ O 的完成

处理 I / O 需要花费 system time,在将 I / O 提交到 disk driver 之前可能要经过 remap, split 和 merge 等操作,并被 I /O scheduler 调度到 request queue。如果处理 I / O 时平均 system time 比较高,超过20%,则要进一步分析下,是不是内核处理 I / O 时的效率有问题。

如果用户空间的 CPU 使用率接近 100%,不一定就代表有问题,可以结合 r 列的进程总数量看下 CPU 的饱和程度。

上面示例可以看到在 CPU 方面有一个明显的问题。user+system 的 CPU 一直维持在 50% 左右,并且 system 消耗了大部分的 CPU。

4. mpstat -P ALL 1

如何快速分析出现性能问题的 Linux 服务器

 mpstat 可以打印按照 CPU 的分解,可以用来检查不不均衡的情况。

上面示例结果可以印证 vmstat 中观察到的结论,并且可以看到服务器有 2 个 CPU,其中 CPU 1 的使用率一直维持在 100%,而 CPU 0 并没有什么负载。CPU 1 的消耗主要在内核空间,而非用户空间。

5. pidstat 1

如何快速分析出现性能问题的 Linux 服务器

默认 pidstat 类似于 top 按照进程的打印方式,不过是以滚动打印的方式,和 top 的清屏方式不同。利用 - p 可以打出指定进程的信息,-p ALL 可以打出所有进程的信息。如果没有指定任何进程默认相当于 -p ALL,但是只打印活动进程的信息(统计非 0 的数据)。

pidstat 不只可以打印进程的 CPU 信息,还可以打印内存,I/ O 等方面的信息,如下是比较有用的信息:

  • pidstat -d 1:看哪些进程有读写。
  • pidstat -r 1:看进程的 page fault 和内存使用。没有发生 page fault 的进程默认不会被打印出来,可以指定 - p 和进程号来打印查看内存。
  • pidstat -t:利用 - t 查看线程信息,可以快速查看线程和期相关线程的关系。
  • pidstat -w:利用 - w 查看进程的 context switch 情况。输出:
    • cswch/s: 每秒发生的 voluntary context switch 数目 (voluntary cs:当进程被 block 在获取不到的资源时,主动发生的 context switch)
    • nvcswch/s: 每秒发生的 non voluntary context switch 数目 (non vloluntary cs:进程执行一段时间用完了 CPU 分配的 time slice,被强制从 CPU 上调度下来,这时发生的 context switch)

上面示例中可以明确得看到是 nc 这个进程在消耗 CPU 1 100% 的 CPU。因为测试系统里消耗 CPU 的进程比较少,所以一目了然,在生产系统中 pidstat 应该能输出更多正在消耗 CPU 的进程情况。

6. iostat -zx 1

如何快速分析出现性能问题的 Linux 服务器

了解块设备 (block device, 这里是 disk) 负载和性能的工具。主要看如下指标:

  • r/s, w/s, rkB/s, wkB/s:每秒完成的读请求次数(read requests, after merges),每秒完成的写请求次数(write requests completed, after merges),每秒读取的千字节数,每秒写入的千字节数。这些指标可以看出 disk 的负载情况。���个性能问题可能仅仅是因为 disk 的负载过大。
  • await:每个 I / O 平均所需的时间,单位为毫秒。await 不仅包括硬盘设备处理 I / O 的时间,还包括了在 kernel 队列中等待的时间 要精确地知道块设备 service 一个 I / O 请求地时间,可供 iostat 读取地内核统计并没有体现,需要用如 blktrace 这样地跟踪工具来跟踪。对于 blktrace 来说,D2C 的时间间隔代表硬件块设备地 service time,Q2C 代表整个 I / O 请求所消耗的时间,即 iostat 的 await。
  • avgqu-sz:队列里的平均 I / O 请求数量 (更恰当的理解应该是平均未完成的 I / O 请求数量)。如果该值大于 1,则有饱和的趋势 (当然设备可以并发地处理请求,特别是一个 front 对多个 backend disk 的虚拟设备)。
  • %util:设备在处理 I / O 的时间占总时间的百分比。表示该设备有 I /O(即非空闲)的时间比率,不考虑 I / O 有多少,只考虑有没有。通常该指标达到 60% 即可能引起性能问题 (可以根据 await 指标进一步求证)。如果指标接近100%,通常就说明出现了饱和。

如果存储设备是一个对应多个后端磁盘的逻辑磁盘,那么 100% 使用率可能仅仅表示一些 I / O 在处理时间占比达到 100%,其他后端磁盘不一定也到达了饱和。请注意磁盘 I / O 的性能问题并不一定会造成应用的问题,很多技术都是使用异步 I / O 操作,所以应用不一定会被 block 或者直接受到延迟的影响。

7. free -m

# free -m
total used free shared buff/cache available
Mem: 7822 129 214 0 7478 7371
Swap: 0 0 0

查看内存使用情况。倒数第二列:

  • buffers: buffer cache,用于 block device I/O。
  • cached: page cache, 用于文件系统。

Linux 用 free memory 来做 cache, 当应用需要时,这些 cache 可以被回收。比如 kswapd 内核进程做页面回收时可能回收 cache;另外手动写 /proc/sys/vm/drop_caches 也会导致 cache 回收。

上面示例中 free 的内存只有 129M,大部分 memory 被 cache 占用。但是系统并没有问题。

8. sar -n DEV 1

如何快速分析出现性能问题的 Linux 服务器

输出指标的含义如下:

  • rxpck/s: Total number of packets received per second.
  • txpck/s: Total number of packets transmitted per second.
  • rxkB/s: Total number of kilobytes received per second.
  • txkB/s: Total number of kilobytes transmitted per second.
  • rxcmp/s: Number of compressed packets received per second (for cslip etc.).
  • txcmp/s: Number of compressed packets transmitted per second.
  • rxmcst/s: Number of multicast packets received per second.
  • %ifutil: Utilization percentage of the network interface. For half-duplex interfaces, utilization is calculated using the sum of rxkB/s and txkB/s as a percentage of the interface speed.
  • For full-duplex, this is the greater of rxkB/S or txkB/s.

这个工具可以查看网络接口的吞吐量,特别是上面蓝色高亮的 rxkB/stxkB/s,这是网络负载,也可以看是否达到了 limit。

9. sar -n TCP,ETCP 1

如何快速分析出现性能问题的 Linux 服务器

输出指标的含义如下:

  • active/sThe number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state per second [tcpActiveOpens].
  • passive/sThe number of times TCP connections have made a direct transition to the SYN-RCVD state from the LISTEN state per second [tcpPassiveOpens].
  • iseg/s: The total number of segments received per second, including those received in error [tcpInSegs]. This count includes segments received on currently established connections.
  • oseg/s: The total number of segments sent per second, including those on current connections but excluding those containing only retransmitted octets [tcpOutSegs].
  • atmptf/s: The number of times per second TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times per second TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state [tcpAttemptFails].
  • estres/s: The number of times per second TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state [tcpEstabResets].
  • retrans/sThe total number of segments retransmitted per second – that is, the number of TCP segments transmitted containing one or more previously transmitted octets [tcpRetransSegs].
  • isegerr/s: The total number of segments received in error (e.g., bad TCP checksums) per second [tcpInErrs].
  • orsts/s: The number of TCP segments sent per second containing the RST flag [tcpOutRsts].

上述蓝色高亮的 3 个指标:active/s, passive/ s 和 retrans/ s 是比较有代表性的指标。

  • active/ s 和 passive/ s 分别是本地发起的每秒新建 TCP 连接数和远程发起的 TCP 新建连接数。这两个指标可以粗略地判断服务器的负载。可以用 active 衡量出站发向,用 passive 衡量入站方向,但也不是完全准确(比如,考虑 localhost 到 localhost 的连接)。
  • retrans 是网络或者服务器发生问题的象征。有可能问题是网络不稳定,比如 Internet 网络问题,或者服务器过载丢包。

10. top

# top
Tasks: 79 total, 2 running, 77 sleeping, 0 stopped, 0 zombie %Cpu(s): 6.0 us, 44.1 sy, 0.0 ni, 49.6 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st KiB Mem : 8010456 total, 7326348 free, 132296 used, 551812 buff/cache KiB Swap: 0 total, 0 free, 0 used. 7625940 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4617 root 20 0 44064 2076 1544 R 100.0 0.0 16:27.23 nc 13634 nginx 20 0 121192 3864 1208 S 0.3 0.0 17:59.85 nginx 1 root 20 0 125372 3740 2428 S 0.0 0.0 6:11.53 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.60 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:17.92 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 7 root rt 0 0 0 0 S 0.0 0.0 0:03.21 migration/0 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh 9 root 20 0 0 0 0 S 0.0 0.0 31:47.62 rcu_sched 10 root rt 0 0 0 0 S 0.0 0.0 0:10.00 watchdog/0

top 是一个常用的命令,包括了多方面的指标。缺点是没有滚动输出(rolling output),不可复现问题发生时不容易保留信息。对于信息保留,用 vmstat 或者 pidstat 等能够提供滚动输出的工具会更好。

示例的问题?

在上面利用工具排查的过程中,我们可以在非常短的时间内快速得到如下结论:

  • 2 个 CPU,nc 这个进程消耗了 CPU 1 100% 的时间,并且时间消耗在 system 内核态。其他进程基本没有在消耗 CPU。
  • 内存 free 比较少,大部分在 cache 中 (并不是问题)。
  • Disk I/ O 非常低,平均读写请求小于 1 个。
  • 收到报文在个位数 KB/ s 级别,每秒有 15 个被动建立的 TCP 连接,没有明显异常。

整个排查过程把系统的问题定位到了进程级别,并且排除一些可能性 (Disk I/ O 和内存)。接下来就是进一步到进程级别的排查,不属于本文的覆盖范围。

正文完
星哥玩云-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2022-01-21发表,共计8569字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中