排查 Linux 中的性能问题并隔离瓶颈

性能问题和瓶颈

当不同操作系统和应用程序中出现性能问题时,每种情况都需要一种独特的方法来进行故障排除。 CPU、内存、网络和输入/输出 (I/O) 是可能出现问题的关键领域。 其中每个区域显示不同的症状 (有时同时) ,需要不同的诊断和解决方案。

性能问题可能是由应用程序或设置的错误配置引起的。 例如,具有未正确配置的缓存层的 Web 应用程序。 这种情况会触发更多请求流回源服务器,而不是从缓存提供。

在另一个示例中,MySQL 或 MariaDB 数据库的重做日志位于操作系统 (操作系统) 磁盘上,或者位于不满足数据库要求的磁盘上。 在此方案中,由于资源竞争和响应时间 (延迟) ,TPS) (每秒事务数可能会减少。

如果完全了解问题,则可以更好地确定在堆栈 (CPU、内存、网络、I/O) 查找的位置。 若要排查性能问题,必须建立 一个基线 ,使你能够在进行更改后比较指标,并评估整体性能是否已提高。

排查虚拟机 (VM) 性能问题与解决物理系统上的性能问题没有什么不同。 这是关于确定哪个资源或组件导致了系统中的 瓶颈

请务必了解瓶颈始终存在。 性能故障排除是关于了解瓶颈在哪里发生以及如何将其移动到不太违规的资源。

本指南可帮助你发现和解决 Azure 虚拟机 Linux 环境中的性能问题。

获取性能指针

可以获取确认或拒绝资源约束是否存在的性能指针。

根据所调查的资源,许多工具可以帮助你获取与该资源相关的数据。 下表包含main资源的示例。

资源 工具
CPU top, htop, mpstat, pidstat, vmstat
磁盘 iostat, iotop, vmstat
网络 ip, vnstat, iperf3
内存 free, top, vmstat

以下各节讨论可用于查找main资源的指针和工具。

CPU 资源

使用或不使用特定百分比的 CPU。 同样,进程要么将时间花在 CPU ((例如 80% 使用率 usr) ),要么不 ((例如 80% 空闲) )。 用于确认 CPU 使用率的main工具为 top

默认情况下,该工具 top 在交互模式下运行。 它每秒刷新一次,并显示按 CPU 使用率排序的进程:

[root@rhel78 ~]$ top
top - 19:02:00 up  2:07,  2 users,  load average: 1.04, 0.97, 0.96
Tasks: 191 total,   3 running, 188 sleeping,   0 stopped,   0 zombie
%Cpu(s): 29.2 us, 22.0 sy,  0.0 ni, 48.5 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
KiB Mem :  7990204 total,  6550032 free,   434112 used,  1006060 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  7243640 avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 22804 root      20   0  108096    616    516 R  99.7  0.0   1:05.71 dd
  1680 root      20   0  410268  38596   5644 S   3.0  0.5   2:15.10 python
   772 root      20   0   90568   3240   2316 R   0.3  0.0   0:08.11 rngd
  1472 root      20   0  222764   6920   4112 S   0.3  0.1   0:00.55 rsyslogd
 10395 theuser   20   0  162124   2300   1548 R   0.3  0.0   0:11.93 top
     1 root      20   0  128404   6960   4148 S   0.0  0.1   0:04.97 systemd
     2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd
     4 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
     6 root      20   0       0      0      0 S   0.0  0.0   0:00.56 ksoftirqd/0
     7 root      rt   0       0      0      0 S   0.0  0.0   0:00.07 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   0:06.00 rcu_sched
    10 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 lru-add-drain
    11 root      rt   0       0      0      0 S   0.0  0.0   0:00.05 watchdog/0
    12 root      rt   0       0      0      0 S   0.0  0.0   0:00.04 watchdog/1
    13 root      rt   0       0      0      0 S   0.0  0.0   0:00.03 migration/1
    14 root      20   0       0      0      0 S   0.0  0.0   0:00.21 ksoftirqd/1
    16 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/1:0H
    18 root      20   0       0      0      0 S   0.0  0.0   0:00.01 kdevtmpfs
    19 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 netns
    20 root      20   0       0      0      0 S   0.0  0.0   0:00.00 khungtaskd
    21 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 writeback
    22 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kintegrityd

现在,查看该输出中的 dd 流程行:

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 22804 root      20   0  108096    616    516 R  99.7  0.0   1:05.71 dd

可以看到, dd 进程占用了 99.7% 的 CPU。

注意

  • 可以通过选择 1 在工具中top显示每个 CPU 的使用情况。

  • 如果进程是多线程的并且跨多个 CPU,则 top 该工具显示的总使用量超过 100%。

另一个有用的参考是负载平均值。 平均负载以 1 分钟、5 分钟和 15 分钟间隔显示平均系统负载。 值指示系统的负载级别。 解释此值取决于可用的 CPU 数。 例如,如果单 CPU 系统上的负载平均值为 2,则系统负载过大,进程开始排队。 如果四 CPU 系统上的负载平均为 2,则总 CPU 使用率约为 50%。

注意

可以通过运行 nproc 命令快速获取 CPU 计数。

在前面的示例中,平均负载为 1.04。 这是一个双 CPU 系统,这意味着 CPU 使用率约为 50%。 如果注意到 48.5% 的空闲 CPU 值,可以验证此结果。 (在 top 命令输出中,空闲 CPU 值显示在 label 之前 id 。)

使用负载平均值作为系统性能的快速概述。

运行 uptime 命令以获取平均负载。

磁盘 (I/O) 资源

调查 I/O 性能问题时,以下术语可帮助你了解问题发生的位置。

术语 描述
IO 大小 每个事务处理的数据量,通常以字节为单位定义。
IO 线程 与存储设备交互的进程数。 此值取决于应用程序。
块大小 后备块设备定义的 I/O 大小。
扇区大小 磁盘上每个扇区的大小。 此值通常为 512 字节。
IOPS 每秒输入输出操作数。
延迟 完成 I/O 操作所需的时间。 此值通常以毫秒为单位, (毫秒) 。
吞吐量 在特定时间内传输的数据量的函数。 此值通常定义为每秒兆字节 (MB/秒) 。

IOPS

每秒输入输出操作 数 (IOPS) 是输入输出 (I/O) 操作数的函数,在本例中为秒 (,秒) 。 I/O 操作可以是读取或写入。 删除或放弃也可以计为针对存储系统的操作。 每个操作都有一个与 I/O 大小相等的分配单元。

I/O 大小通常在应用程序级别定义为每个事务写入或读取的数据量。 常用的 I/O 大小为 4K。 但是,包含更多线程的较小 I/O 大小会产生更高的 IOPS 值。 由于每个事务的完成速度相对较快, (因为其大小) 较小,因此较小的 I/O 可以在相同的时间内完成更多的事务。

相反,假设线程数相同,但使用更大的 I/O。 IOPS 会降低,因为每个事务完成时间更长。 但是,吞吐量会增加。

请考虑下面的示例:

1,000 IOPS 意味着每秒完成一千个操作。 每个操作大约需要 1 毫秒。 (一秒内有 1,000 毫秒。) 理论上,每个事务大约需要 1 毫秒才能完成,或大约 1 毫秒的延迟。

通过了解 IOSize 值和 IOPS,可以通过将 IOSize 乘以 IOPS 来计算吞吐量。

例如:

  • 4K IOSize 时的 1,000 IOPS = 4,000 KB/秒,或 4 MB/秒 (3.9 MB/秒,以精确)

  • 1M IOSize 时的 1,000 IOPS = 1,000 MB/秒,或 1 GB/s (976 MB/秒精确)

更易用公式的版本可以编写如下:

IOPS * IOSize = IOSize/s (Throughput)

吞吐量

与 IOPS 不同,吞吐量是一段时间内数据量的函数。 这意味着,每秒都会写入或读取一定数量的数据。 此速度以 <数据>/<时间>量或每秒兆字节 (MB/秒) 进行度量。

如果知道吞吐量和 IOSize 值,可以通过将吞吐量除以 IOSize 来计算 IOPS。 应将单位规范化为最小的内涵。 例如,如果 IOSize 以 kb (kb) 进行定义,则应转换吞吐量。

公式格式编写如下:

Throughput / IOSize = IOPS

若要将此公式放入上下文中,请考虑在 IOSize 为 4K 时吞吐量为 10 MB/秒。 在公式中输入值时,结果为 10,240/4=2,560 IOPS

注意

10 MB 正好等于 10,240 KB。

延迟

延迟是每个操作完成所花费的平均时间的度量值。 IOPS 和延迟是相关的,因为这两个概念都是时间的函数。 例如,在 100 IOPS 时,每个操作大约需要 10 毫秒才能完成。 但是,以较低的 IOPS 可以更快地提取相同量的数据。 延迟也称为寻道时间。

了解 iostat 输出

作为 sysstat 包的一部分, iostat 该工具提供有关磁盘性能和使用情况指标的见解。 iostat 可帮助识别与磁盘子系统相关的瓶颈。

可以在一个简单的命令中运行 iostat 。 基本语法如下:

iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>

参数指示提供的信息 iostat 。 没有任何命令参数, iostat 则显示基本详细信息:

[host@rhel76 ~]$ iostat
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76)       08/05/2019      _x86_64_        (1 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          41.06    0.00   30.47   21.00    0.00    7.47
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             182.77      5072.69      1066.64     226090      47540
sdd               2.04        42.56        22.98       1897       1024
sdb              12.61       229.23     96065.51      10217    4281640
sdc               2.56        46.16        22.98       2057       1024
md0               2.67        73.60        45.95       3280       2048

默认情况下, iostat 显示所有现有块设备的数据,尽管为每个设备提供的数据最少。 提供扩展数据 ((例如吞吐量、IOPS、队列大小和延迟) )来帮助识别问题的参数。

通过指定触发器运行 iostat

sudo iostat -dxctm 1

若要进一步扩展 iostat 结果,请使用以下参数。

参数 操作
-d 显示设备利用率报告。
-x 显示扩展统计信息。 此参数非常重要,因为它提供 IOPS、延迟和队列大小。
-c 显示 CPU 使用率报告。
-t 打印显示的每个报表的时间。 此参数对于长运行非常有用。
-m 以每秒兆字节为单位显示统计信息,这是一种更易于阅读的形式。

命令中的数字 1 指示 iostat 每秒刷新一次。 若要停止刷新,请选择 Ctrl+C

如果包含额外的参数,输出将类似于以下文本:

    [host@rhel76 ~]$ iostat -dxctm 1
    Linux 3.10.0-957.21.3.el7.x86_64 (rhel76)       08/05/2019      _x86_64_        (1 CPU)
        08/05/2019 07:03:36 PM
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               3.09    0.00    2.28    1.50    0.00   93.14
    
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    sda               0.02     0.52    9.66    2.46     0.31     0.10    70.79     0.27   23.97    6.68   91.77   2.94   3.56
    sdd               0.00     0.00    0.12    0.00     0.00     0.00    64.20     0.00    6.15    6.01   12.50   4.44   0.05
    sdb               0.00    22.90    0.47    0.45     0.01     5.74 12775.08     0.17  183.10    8.57  367.68   8.01   0.74
    sdc               0.00     0.00    0.15    0.00     0.00     0.00    54.06     0.00    6.46    6.24   14.67   5.64   0.09
    md0               0.00     0.00    0.15    0.01     0.00     0.00    89.55     0.00    0.00    0.00    0.00   0.00   0.00

了解值

下表显示了输出中的iostatmain列。

说明
r/s 每秒读取数 (IOPS)
w/s 每秒写入数 (IOPS)
rMB/s 每秒读取兆字节 (吞吐量)
wMB/s 每秒写入兆字节 (吞吐量)
avgrq-sz 扇区的平均 I/O 大小;将此数字乘以扇区大小(通常为 512 字节)来获取 I/O 大小 (I/O 大小)
avgqu-sz 平均队列大小 (排队等待服务的 I/O 操作数)
await 设备提供的 I/O 的平均时间 (延迟)
r_await 设备提供的 I/O 的平均读取时间(以毫秒为单位), (延迟)
w_await 设备提供的 I/O 的平均读取时间(以毫秒为单位), (延迟)

提供 iostat 的数据是信息性的,但某些列中存在某些数据并不意味着存在问题。 应始终捕获和分析中的数据 iostat ,以找出可能的瓶颈。 高延迟可能表示磁盘已达到饱和点。

注意

可以使用 pidstat -d 命令查看每个进程的 I/O 统计信息。

网络资源

网络可能会遇到两main瓶颈:低带宽和高延迟。

可以使用 vnstat 实时捕获带宽详细信息。 但是, vnstat 并非在所有分发版中都可用。 广泛可用的 iptraf-ng 工具是查看实时接口流量的另一个选项。

网络延迟

可以使用 Internet 控制消息协议中的简单 ping 命令来确定两个不同系统中的网络延迟 (ICMP) :

[root@rhel78 ~]# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=5.33 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=5.24 ms
^C
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.240/5.291/5.339/0.035 ms

若要停止 ping 活动,请选择 Ctrl+C

网络带宽

可以使用等 iperf3工具验证网络带宽。 该工具 iperf3 适用于服务器/客户端模型,通过指定 -s 服务器上的 标志来启动应用程序。 然后,客户端通过指定 IP 地址或完全限定的域名来连接到服务器, (FQDN) 标志 -c 。 以下代码片段演示如何 iperf3 在服务器和客户端上使用该工具。

  • 服务器

    root@ubnt:~# iperf3 -s
    -----------------------------------------------------------
    Server listening on 5201
    -----------------------------------------------------------
    
  • 客户端

    root@ubnt2:~# iperf3 -c 10.1.0.4
    Connecting to host 10.1.0.4, port 5201
    [  5] local 10.1.0.4 port 60134 connected to 10.1.0.4 port 5201
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec  5.78 GBytes  49.6 Gbits/sec    0   1.25 MBytes
    [  5]   1.00-2.00   sec  5.81 GBytes  49.9 Gbits/sec    0   1.25 MBytes
    [  5]   2.00-3.00   sec  5.72 GBytes  49.1 Gbits/sec    0   1.25 MBytes
    [  5]   3.00-4.00   sec  5.76 GBytes  49.5 Gbits/sec    0   1.25 MBytes
    [  5]   4.00-5.00   sec  5.72 GBytes  49.1 Gbits/sec    0   1.25 MBytes
    [  5]   5.00-6.00   sec  5.64 GBytes  48.5 Gbits/sec    0   1.25 MBytes
    [  5]   6.00-7.00   sec  5.74 GBytes  49.3 Gbits/sec    0   1.31 MBytes
    [  5]   7.00-8.00   sec  5.75 GBytes  49.4 Gbits/sec    0   1.31 MBytes
    [  5]   8.00-9.00   sec  5.75 GBytes  49.4 Gbits/sec    0   1.31 MBytes
    [  5]   9.00-10.00  sec  5.71 GBytes  49.1 Gbits/sec    0   1.31 MBytes
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate         Retr
    [  5]   0.00-10.00  sec  57.4 GBytes  49.3 Gbits/sec    0             sender
    [  5]   0.00-10.04  sec  57.4 GBytes  49.1 Gbits/sec                  receiver
    
    iperf Done.
    

下表显示了客户端的一些常见 iperf3 参数。

参数 说明
-P 指定要运行的并行客户端流数。
-R 反向流量。 默认情况下,客户端将数据发送到服务器。
--bidir 测试上传和下载。

内存资源

内存是用于检查的另一种故障排除资源,因为应用程序可能或可能不会使用部分内存。 可以使用 和 topfree工具查看总体内存利用率,并确定各种进程消耗的内存量:

[root@rhel78 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           7802         435        5250           9        2117        7051
Swap:             0           0           0

在 Linux 系统中,内存利用率通常为 99%。 在输出中 free ,有一个名为 buff/cache的列。 Linux 内核使用可用 (未使用的) 内存来缓存 I/O 请求,以提高响应时间。 此过程称为 页面缓存。 在内存压力 (内存运行) 较低的情况下,内核返回用于 页面缓存 的内存,以便应用程序可以使用该内存。

在输出中 free可用 列指示可供进程使用多少内存。 此值是通过添加 buff/cache 内存量和可用内存来计算的。

可以将 命令配置为 top 按内存利用率对进程进行排序。 默认情况下, top 按 CPU 百分比 (%) 排序。 若要按内存利用率 (%) 排序,请在运行 top时选择 Shift+M。 以下文本显示了 命令的 top 输出:

[root@rhel78 ~]# top
top - 22:40:15 up  5:45,  2 users,  load average: 0.08, 0.08, 0.06
Tasks: 194 total,   2 running, 192 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.3 us, 41.8 sy,  0.0 ni, 45.4 id,  0.0 wa,  0.0 hi,  0.5 si,  0.0 st
KiB Mem :  7990204 total,   155460 free,  5996980 used,  1837764 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1671420 avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 45283 root      20   0 5655348   5.3g    512 R  99.7 69.4   0:03.71 tail
  3124 omsagent  20   0  415316  54112   5556 S   0.0  0.7   0:30.16 omsagent
  1680 root      20   0  413500  41552   5644 S   3.0  0.5   6:14.96 python
[...]

RES 指示 常驻内存。 这表示实际的进程使用情况。 该工具 top 提供与 KB) 千字节 (类似的输出 free

如果应用程序遇到内存 泄漏,内存利用率可能会超过预期。 在内存泄漏方案中,应用程序无法释放不再使用的内存页。

下面是另一个用于查看内存消耗量最大的进程的命令:

ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head

以下文本显示了 命令的示例输出:

[root@rhel78 ~]# ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
   PID COMMAND         USER     COMMAND                     %CPU %MEM
 45922 tail            root     tail -f /dev/zero           82.7 61.6
[...]

可以从内存不足 (OOM) Kill 事件中识别内存压力,如以下示例输出中所示:

Jun 19 22:42:14 rhel78 kernel: Out of memory: Kill process 45465 (tail) score 902 or sacrifice child
Jun 19 22:42:14 rhel78 kernel: Killed process 45465 (tail), UID 0, total-vm:7582132kB, anon-rss:7420324kB, file-rss:0kB, shmem-rss:0kB

在 RAM (物理内存) 和 SWAP (磁盘) 消耗后调用 OOM。

注意

可以使用 pidstat -r 命令查看每个进程的内存统计信息。

确定资源约束是否存在

可以通过使用前面的指示器并了解当前配置来确定约束是否存在。 可以将约束与现有配置进行比较。

下面是磁盘约束的示例:

D2s_v3 VM 能够 48 MB/秒的未缓存吞吐量。 对于此 VM,附加了一个能够 200 MB/秒的 P30 磁盘。 应用程序至少需要 100 MB/秒。

在此示例中,限制资源是整个 VM 的吞吐量。 应用程序的要求与磁盘或 VM 配置可以提供的要求指示约束资源。

如果应用程序需要 <measurement1><资源>,并且资源的>当前配置<只能<提供 measurement2>,则此要求可能是一个限制因素。

定义限制资源

确定资源是当前配置中的限制因素后,确定如何更改资源以及它如何影响工作负荷。 在某些情况下,由于成本节约措施,可能会存在资源限制,但应用程序仍能够处理瓶颈,而不会出现问题。

例如:

如果应用程序需要 128 GB (测量) RAM (资源) ,并且 当前 RAM (资源) 配置只能提供 64 GB (测量) ,则此要求可能是一个限制因素。

现在,可以定义限制资源并基于该资源执行操作。 同一概念也适用于其他资源。

如果预期这些限制资源是成本节约措施,则应用程序应解决瓶颈问题。 但是,如果存在相同的成本节约措施,并且应用程序无法轻松处理缺少资源的情况,则此配置可能会导致问题。

根据获取的数据进行更改

性能设计不是为了解决问题,而是要了解下一个瓶颈可能出现在哪里以及如何解决它。 瓶颈始终存在,只能移动到设计的不同位置。

例如,如果应用程序受到磁盘性能的限制,则可以增加磁盘大小以允许更多吞吐量。 但是,网络随后成为下一个瓶颈。 由于资源有限,因此没有理想的配置,必须定期解决问题。

通过在前面的步骤中获取数据,现在可以根据实际、可衡量的数据进行更改。 还可以将这些更改与之前测量的基线进行比较,以验证是否存在有形差异。

请考虑下面的示例:

在应用程序运行时获取基线时,确定系统在两个 CPU 的配置中具有 100% 的 CPU 使用率。 你观察到的负载平均值为 4。 这意味着系统正在排队请求。 对 8 CPU 系统的更改将 CPU 使用率降低到 25%,在应用相同负载时,平均负载减少到 2。

在此示例中,将获取的结果与更改的资源进行比较时,存在可度量的差异。 在更改之前,有一个明确的资源约束。 但在更改后,有足够的资源来增加负载。

从本地迁移到云

从本地设置到云计算的迁移可能会受到一些性能差异的影响。

CPU

根据体系结构,本地设置可能会运行具有更高时钟速度和更大缓存的 CPU。 结果将缩短处理时间,并增加每个周期 (IPC) 指令。 处理迁移时,请务必了解 CPU 模型和指标的差异。 在这种情况下,CPU 计数之间的一对一关系可能不够。

例如:

在具有 4 个以 3.7 GHz 运行的 CPU 的本地系统中,总共有 14.8 GHz 可供处理。 如果使用由 2.1 GHz CPU 支持的D4s_v3 VM 创建 CPU 计数中的等效项,则迁移的 VM 有 8.1 GHz 可供处理。 这表示性能下降约 44%。

磁盘

Azure 中的磁盘性能由磁盘 (的类型和大小定义,超级磁盘除外,后者在大小、IOPS 和吞吐量) 方面提供灵活性。 磁盘大小定义 IOPS 和吞吐量限制。

延迟是一个指标,它取决于磁盘类型,而不是磁盘大小。 大多数本地存储解决方案都是具有 DRAM 缓存的磁盘阵列。 这种类型的缓存提供亚毫秒 (大约 200 微秒) 延迟和高读/写吞吐量 (IOPS) 。

下表显示了平均 Azure 延迟。

磁盘类型 延迟
超级磁盘/高级 SSD v2 三位数 μs (微秒)
高级 SSD/标准 SSD 个位数毫秒 (毫秒)
标准 HDD 两位数毫秒 (毫秒)

注意

如果磁盘达到其 IOPS 或带宽限制,则会受到限制,否则延迟可能会激增到 100 毫秒或更多。

本地 () 与高级 SSD 之间的延迟差通常小于 1 毫秒, (个位数毫秒) 成为限制因素。 请注意存储产品/服务之间的延迟差异,并选择更符合应用程序要求的产品/服务。

网络

大多数本地网络设置使用 10 Gbps 链接。 在 Azure 中,网络带宽直接由虚拟机 (VM 的大小) 定义。 某些网络带宽可能超过 40 Gbps。 请确保选择的大小具有足够的带宽以满足应用程序需求。 在大多数情况下,限制因素是 VM 或磁盘(而不是网络)的吞吐量限制。

内存

选择一个 VM 大小,该大小具有足够的 RAM,适合当前配置的内容。

性能诊断 (PerfInsights)

PerfInsights 是Azure 支持针对 VM 性能问题的建议工具。 它旨在涵盖 CPU、内存和 I/O 的最佳做法和专用分析选项卡。 可以通过Azure 门户或从 VM 内部运行 OnDemand,然后与Azure 支持团队共享数据。

运行 PerfInsights

PerfInsights 适用于 WindowsLinux OS。 验证 Linux 分发版是否在 Linux 性能诊断 支持的分发 版列表中。

通过Azure 门户运行和分析报表

通过 Azure 门户安装 PerfInsights 时,软件会在 VM 上安装扩展。 用户还可以直接转到“VM 中的扩展”边栏选项卡,然后选择性能诊断选项,将 PerfInsights 安装为扩展。

Azure 门户选项 1

浏览 VM 边栏选项卡,然后选择“性能诊断”选项。 系统会要求你安装选项, (在所选的 VM 上使用扩展) 。

显示“性能诊断报告”屏幕并要求用户安装性能诊断的屏幕截图。

Azure 门户选项 2

浏览到“VM”边栏选项卡中的“诊断和解决问题”选项卡,然后在“VM 性能问题”下查找“故障排除”链接。

显示 VM 边栏选项卡中的“诊断和解决问题”选项卡的屏幕截图,以及“VM 性能问题”下的“故障排除”链接。

PerfInsights 报表中要查找的内容

运行 PerfInsights 报表后,内容的位置取决于报表是通过Azure 门户运行的还是作为可执行文件运行的。 对于任一选项,访问生成的日志文件夹或 ((如果在 Azure 门户) 下载本地进行分析)。

运行Azure 门户

显示“性能诊断报告”屏幕并突出显示生成的诊断报告的屏幕截图。

打开 PerfInsights 报表。 “ 发现 ”选项卡记录资源消耗量的任何离群值。 如果由于特定资源使用而出现性能降低的情况,“ 发现 ”选项卡会将每个发现分类为 “影响大 ”或“ 中等 影响”。

例如,在以下报告中,我们看到检测到与存储相关的 中等 影响结果,并看到相应的建议。 如果展开“ 发现” 事件,将看到几个关键详细信息。

显示 PerfInsights 报表并详细说明报表结果的屏幕截图,包括影响级别、查找、受影响的资源和建议。

有关 Linux OS 中的 PerfInsight 的详细信息,请参阅 如何在 Microsoft Azure 中使用 PerfInsights Linux

更多信息

联系我们寻求帮助

如果你有任何疑问或需要帮助,请创建支持请求联系 Azure 社区支持。 还可以向 Azure 反馈社区提交产品反馈。