在 Linux 中排查性能问题并隔离瓶颈
适用于：✔️ Linux VM
性能问题和瓶颈
当不同的操作系统和应用程序中出现性能问题时，每种情况都需要采用独特的方法进行故障排除。 CPU、内存、网络和输入/输出 (I/O) 是最容易发生问题的区域。 其中每个区域都会表现出不同的症状（有时同时出现），需要不同的诊断和解决方案。
性能问题可能是应用程序或设置配置不当造成的。 例如，具有未正确配置的缓存层的 Web 应用程序。 这种情况会触发更多的请求流回源服务器，而不是从缓存中提供服务。
在另一个示例中，MySQL 或 MariaDB 数据库的重做日志位于操作系统（OS）磁盘或不符合数据库要求的磁盘上。 在此方案中，由于资源的竞争和更高的响应时间（延迟），每秒事务数（TPS）可能会减少。
如果完全了解此问题，可以更好地确定堆栈上的位置（CPU、内存、网络、I/O）。 若要排查性能问题，必须建立一个 基线 ，用于在进行更改后比较指标，并评估整体性能是否有所改善。
排查虚拟机（VM）性能问题与解决物理系统上的性能问题不同。 这是关于确定哪个资源或组件导致系统中的 瓶颈 。
请务必了解瓶颈始终存在。 性能故障排除完全是了解瓶颈的发生位置以及如何将其移动到不太有问题的资源。
本指南可帮助你发现和解决 Linux 环境中的 Azure 虚拟机中的性能问题。
获取性能指针
可以获取确认或拒绝资源约束是否存在的性能指针。
根据调查的资源，许多工具可以帮助你获取与该资源相关的数据。 下表包含主要资源的示例。
| 资源 | 工具 |
|---|---|
| CPU | top、、htopmpstat、pidstat、vmstat |
| 磁盘 | iostat、 iotop、、 vmstat |
| 网络 | ip、 vnstat、、 iperf3 |
| 内存 | free、 top、、 vmstat |
后续部分将讨论可用于查找主要资源的指针和工具。
CPU 资源
使用或不使用特定百分比的 CPU。 同样，进程要么花费在 CPU（如 80% usr 使用率）中，要么不（例如 80% 空闲）。 确认 CPU 使用率的主要工具是 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 值显示在标签之前 id 。
使用负载平均值快速概述系统的性能。
uptime运行命令以获取负载平均值。
磁盘 （I/O） 资源
调查 I/O 性能问题时，以下术语可帮助你了解问题发生的位置。
| 术语 | 说明 |
|---|---|
| IO 大小 | 每个事务处理的数据量，通常以字节为单位定义。 |
| IO 线程 | 与存储设备交互的进程数。 此值取决于应用程序。 |
| 块大小 | 支持块设备定义的 I/O 大小。 |
| 扇区大小 | 磁盘上每个扇区的大小。 此值通常为 512 字节。 |
| IOPS | 每秒输入输出操作数。 |
| 延迟 | I/O 操作完成的时间。 此值通常以毫秒为单位（ms）。 |
| 吞吐量 | 传输的数据量函数，该量在特定时间内传输。 此值通常定义为每秒兆字节（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,000 毫秒。从理论上讲，每个事务的完成时间大约为 1 毫秒，或大约 1 毫秒的延迟。
通过了解 IOSize 值和 IOPS，可以通过将 IOSize 乘以 IOPS 来计算吞吐量。
例如：
1,000 IOPS，4K IOSize = 4,000 KB/秒，或 4 MB/秒（精确 3.9 MB/秒）
1,000 IOPS（以 1M IOSize 表示 1,000 MB/秒）或 1 GB/秒（精确为 976 MB/秒）
可以按如下所示编写更易公式的版本：
IOPS * IOSize = IOSize/s (Throughput)
吞吐量
与 IOPS 不同，吞吐量是一段时间内数据的函数。 这意味着，每秒都会写入或读取一定量的数据。 此速度以<数据/<>量时间>或每秒兆字节（MB/秒）来测量。
如果知道吞吐量和 IOSize 值，可以通过将吞吐量除以 IOSize 来计算 IOPS。 应将单位规范化为最小内涵。 例如，如果 IOSize 以 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
了解值
下表显示了输出中的 iostat 主列。
| 列 | 说明 |
|---|---|
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 统计信息。
网络资源
网络可能会遇到两个主要瓶颈：低带宽和高延迟。
可用于 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 |
测试上传和下载。 |
内存资源
内存是用于检查的另一种故障排除资源，因为应用程序可能或可能不会使用部分内存。 可以使用诸如和top查看总体内存利用率的工具free，并确定各种进程消耗的内存量：
[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 百分比进行排序 。。 若要按内存利用率进行排序 ，请在运行时选择 Shift+M。 top 以下文本显示命令的 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） 终止 事件的内存压力，如以下示例输出中所示：
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 时 CPU 使用率为 100%。 你观察到的负载平均值为 4。 这意味着系统正在排队请求。 对 8 CPU 系统的更改将 CPU 使用率降低到 25%，应用相同负载时，负载平均值减少到 2。
在此示例中，将获取的结果与更改的资源进行比较时，存在可度量的差异。 在更改之前，存在明确的资源约束。 但在更改后，有足够的资源来增加负载。
从本地迁移到云
从本地设置迁移到云计算可能会受到多种性能差异的影响。
CPU
根据体系结构，本地设置可能会运行具有更高时钟速度和更大缓存的 CPU。 结果将减少处理时间和更高的每个周期指令（IPC）。 在处理迁移时，请务必了解 CPU 模型和指标之间的差异。 在这种情况下，CPU 计数之间的一对一关系可能不够。
例如：
在本地系统中，有四个 CPU 在 3.7 GHz 上运行，总共有 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 | 单位数 ms （毫秒） |
| 标准 HDD | 两位数 ms （毫秒） |
注意
如果磁盘达到其 IOPS 或带宽限制，将受到限制，否则延迟可能会飙升到 100 毫秒或更多。
本地（通常小于毫秒）和高级 SSD（单位数毫秒）之间的延迟差将成为一个限制因素。 请注意存储产品/服务之间的延迟差异，并选择更符合应用程序要求的套餐。
网络
大多数本地网络设置使用 10 Gbps 链接。 在 Azure 中，网络带宽直接由虚拟机（VM）的大小定义。 某些网络带宽可能超过 40 Gbps。 请确保选择具有足够带宽的大小，以满足应用程序需求。 在大多数情况下，限制因素是 VM 或磁盘的吞吐量限制，而不是网络。
内存
选择具有足够 RAM 的 VM 大小，以便为当前配置的内容。
性能诊断 （PerfInsights）
PerfInsights 是针对 VM 性能问题的Azure 支持建议的工具。 它旨在涵盖 CPU、内存和 I/O 的最佳做法和专用分析选项卡。 可以通过Azure 门户或 VM 内部运行 OnDemand，然后与Azure 支持团队共享数据。
运行 PerfInsights
PerfInsights 适用于 Windows 和 Linux OS。 验证 Linux 分发是否在 Linux 性能诊断支持的分发版列表中。
通过Azure 门户运行和分析报表
通过 Azure 门户 安装 PerfInsights 时，软件会在 VM 上安装扩展。 用户还可以直接转到 VM 边栏选项卡中的“扩展”，然后选择性能诊断选项，将 PerfInsights 安装为扩展。
Azure 门户选项 1
浏览 VM 边栏选项卡并选择 “性能诊断 ”选项。 系统要求你在为其选择该选项的 VM 上安装选项（使用扩展）。
Azure 门户选项 2
浏览到 VM 边栏选项卡中的“诊断和解决问题”选项卡，并查找 VM 性能问题下的“故障排除”链接。
在 PerfInsights 报表中查找的内容
运行 PerfInsights 报表后，内容的位置取决于报表是通过Azure 门户运行还是作为可执行文件运行。 对于任一选项，访问生成的日志文件夹，或者（如果在本地Azure 门户中）下载进行分析。
运行Azure 门户
打开 PerfInsights 报表。 “ 查找 ”选项卡根据资源消耗记录任何离群值。 如果由于特定资源使用率而性能缓慢，则 “查找 ”选项卡会将每个发现分类为 “高 影响”或 “中等 影响”。
例如，在以下报告中，我们看到 检测到与存储相关的中等 影响结果，并看到相应的建议。 如果展开 “查找” 事件，则会看到几个关键详细信息。
有关 Linux OS 中的 PerfInsights 的详细信息，请参阅 如何在 Azure Microsoft中使用 PerfInsights Linux。
详细信息
联系我们寻求帮助
如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。