标签 性能 下的文章

不久前,识别硬件瓶颈还需要深厚的专业知识。今天的开源 GUI 性能监视器使它变得相当简单。

 title=

计算机是一个集成的系统,它的性能取决于最慢的硬件组件。如果一个组件的能力比其他组件差,性能落后而不能跟上,它就会拖累你的整个系统。这就是一个 性能瓶颈。消除一个严重的瓶颈可以使你的系统飞起来。

本文解释了如何识别 Linux 系统中的硬件瓶颈。这些技术同时适用于个人的电脑和服务器。我强调的是个人电脑 —— 我不会涉及局域网管理或数据库系统等领域的服务器特定的瓶颈。这些通常涉及专门的工具。

我也不会多谈解决方案。这对本文来说是个太大的话题。相反,我将写一篇关于性能调整的后续文章。

我将只使用开源的图形用户界面(GUI)工具来完成这项工作。大多数关于 Linux 瓶颈的文章都相当复杂。它们使用专门的命令,并深入研究神秘的细节。

开源提供的 GUI 工具使得识别许多瓶颈变得简单。我的目标是给你一个快速、简单的方法,你可以在任何地方使用。

从哪里开始

一台计算机由六个关键的硬件资源组成。

  • 处理器
  • 内存
  • 存储器
  • USB 端口
  • 互联网连接
  • 图形处理器

如果任何一个资源表现不佳,就会产生一个性能瓶颈。为了识别瓶颈,你必须监测这六种资源。

开源提供了大量的工具来完成这项工作。我会使用 GNOME 系统监视器。它的输出很容易理解,而且你可以在大多数软件库中找到它。

启动它并点击“资源”标签。你可以马上发现许多性能问题。

 title=

图 1. 系统监控器发现问题。(Howard Fosdick, CC BY-SA 4.0)

在“资源”面板上显示三个部分:CPU 历史、内存和交换历史,以及网络历史。一眼就能看出你的处理器是否不堪负荷了,还是你的电脑没有内存了,抑或你的网络带宽被用光了。

我将在下面探讨这些问题。现在,当你的电脑速度变慢时,首先检查系统监视器。它可以立即为你提供最常见的性能问题的线索。

现在让我们来探讨一下如何识别特定方面的瓶颈。

如何识别处理器的瓶颈

要发现瓶颈,你必须首先知道你有什么硬件。开源为这个目的提供了几个工具。我喜欢 HardInfo,因为它的屏幕显示很容易阅读,而且广泛流行。

启动 HardInfo。它的“计算机->摘要”面板可以识别你的 CPU 并告诉你它的核心数、线程数和速度。它还能识别你的主板和其他计算机部件。

 title=

图 2. HardInfo 显示了硬件细节。(Howard Fosdick, CC BY-SA 4.0)

HardInfo 显示,这台计算机有一个物理 CPU 芯片。该芯片包含两个处理器(或称为核心)。每个核心支持两个线程(或称为逻辑处理器)。这就是总共四个逻辑处理器 —— 正是图 1 中系统监控器的 CPU 历史部分所显示的。

当处理器不能在其时间内对请求做出反应时,就会出现 处理器瓶颈,说明它们已经很忙了。

当系统监控器显示逻辑处理器的利用率持续在 80% 或 90% 以上时,你就可以确定这一点。这里有一个例子,四个逻辑处理器中有三个被淹没在 100% 的利用率中。这是一个瓶颈,因为它没有留下多少 CPU 用于其他工作。

 title=

图 3. 一个处理器的瓶颈。(Howard Fosdick, CC BY-SA 4.0)

哪个程序导致了这个问题?

你需要找出是哪个程序在消耗所有的 CPU。点击系统监视器的“进程”标签。然后点击“CPU 百分比”标头,根据它们消耗的 CPU 的多少对进程进行排序。你将看到哪些应用程序正在扼杀你的系统。

 title=

图 4. 识别违规的进程。(Howard Fosdick, CC BY-SA 4.0)

前三个进程各消耗了 总 CPU 资源的 24%。由于有四个逻辑处理器,这意味着每个进程消耗了一整个处理器。这就像图 3 所示。

在“进程”面板上,一个名为“analytical\_AI”的程序被确定为罪魁祸首。你可以在面板上右键单击它,以查看其资源消耗的更多细节,包括内存使用、它所打开的文件、其输入/输出细节,等等。

如果你的登录会话有管理员权限,你可以管理这个进程。你可以改变它的优先级,并停止、继续、结束或杀死它。因此,你可以在这里立即解决你的瓶颈问题。

 title=

图 5. 右键点击一个进程来管理它。(Howard Fosdick, CC BY-SA 4.0)

如何解决处理瓶颈问题?除了实时管理违规的进程外,你也可以防止瓶颈的发生。例如,你可以用另一个应用程序来代替违规进程,绕过它,改变你使用该应用程序的行为,将该应用程序安排在非工作时间,解决潜在的内存问题,对该应用程序或你的系统软件进行性能调整,或升级你的硬件。这里涉及的内容太多,所以我将在下一篇文章中探讨这些方式。

常见的处理器瓶颈

在用系统监控器监控你的 CPU 时,你会遇到几种常见的瓶颈问题。

有时一个逻辑处理器出现瓶颈,而其他所有的处理器都处于低利用率。这意味着你有一个应用程序,它的代码不够智能,无法利用一个以上的逻辑处理器,而且它已经把正在使用的那个处理器耗尽了。这个应用程序完成的时间将比使用更多的处理器要长。但另一方面,至少它能让你的其他处理器腾出手来做别的工作,而不会接管你的电脑。

你也可能看到一个逻辑处理器永远停留在 100% 的利用率。要么它非常忙,要么是一个进程被挂起了。判断它是否被挂起的方法是,是看该进程是否从不进行任何磁盘活动(正如系统监视器“进程”面板所显示的那样)。

最后,你可能会注意到,当你所有的处理器都陷入瓶颈时,你的内存也被完全利用了。内存不足的情况有时会导致处理器瓶颈。在这种情况下,你要解决的是根本的内存问题,而不是体现出症状的 CPU 问题。

如何识别内存瓶颈

鉴于现代 PC 中有大量的内存,内存瓶颈比以前要少得多。然而,如果你运行内存密集型程序,特别是当你的计算机没有很多的随机存取内存(RAM)时,你仍然可能遇到这些问题。

Linux 使用内存 既用于程序,也用于缓存磁盘数据。后者加快了磁盘数据的访问速度。Linux 可以在它需要的任何时候回收这些内存供程序使用。

系统监视器的“资源”面板显示了你的总内存和它被使用的程度。在“进程”面板上,你可以看到单个进程的内存使用情况。

下面是系统监控器“资源”面板中跟踪总内存使用的部分。

 title=

图 6. 一个内存瓶颈。(Howard Fosdick, CC BY-SA 4.0)

在“内存”的右边,你会注意到 交换空间。这是 Linux 在内存不足时使用的磁盘空间。它将内存写入磁盘以继续操作,有效地将交换空间作为你的内存的一个较慢的扩展。

你要注意的两个内存性能问题是:

  1. 内存被大量使用,而且你看到交换空间的活动频繁或不断增加。
  2. 内存和交换空间都被大量使用。

情况一意味着更慢的性能,因为交换空间总是比内存更慢。你是否认为这是一个性能问题,取决于许多因素(例如,你的交换空间有多活跃、它的速度、你的预期,等等)。我的看法是,对于现代个人电脑来说,交换空间任何超过象征性的使用都是不可接受的。

情况二是指内存和交换空间都被大量使用。这是一个 内存瓶颈。计算机变得反应迟钝。它甚至可能陷入一种“咆哮”的状态,在这种状态下,除了内存管理之外,它几乎不能完成其他任务。

上面的图 6 显示了一台只有 2GB 内存的旧电脑。当内存使用量超过 80% 时,系统开始向交换空间写入,响应速度下降了。这张截图显示了内存使用量超过了 90%,而且这台电脑已经无法使用。

解决内存问题的最终答案是要么少用内存,要么多买内存。我将在后续文章中讨论解决方案。

如何识别存储瓶颈

如今的存储有固态和机械硬盘等多个品种。设备接口包括 PCIe、SATA、雷电和 USB。无论有哪种类型的存储,你都要使用相同的程序来识别磁盘瓶颈。

从系统监视器开始。它的“进程”面板显示各个进程的输入/输出率。因此,你可以快速识别哪些进程做了最多的磁盘 I/O。

但该工具并不显示每个磁盘的总数据传输率。你需要查看特定磁盘上的总负载,以确定该磁盘是否是一个存储瓶颈。

要做到这一点,使用 atop 命令。它在大多数 Linux 软件库中都有。

只要在命令行提示符下输入 atop 即可。下面的输出显示,设备 sdb 达到 busy 101%。很明显,它已经达到了性能极限,限制了你的系统完成工作的速度。

 title=

图 7. atop 命令识别了一个磁盘瓶颈。(Howard Fosdick, CC BY-SA 4.0)

注意到其中一个 CPU 有 85% 的时间在等待磁盘完成它的工作(cpu001 w 85%)。这是典型的存储设备成为瓶颈的情况。事实上,许多人首先看 CPU 的 I/O 等待时间来发现存储瓶颈。

因此,要想轻松识别存储瓶颈,请使用 atop 命令。然后使用系统监视器上的“进程”面板来识别导致瓶颈的各个进程。

如何识别 USB 端口的瓶颈

有些人整天都在使用他们的 USB 端口。然而,他们从不检查这些端口是否被最佳地使用。无论你是插入外部磁盘、U 盘,还是其他东西,你都要确认你是否从 USB 连接的设备中获得了最大性能。

这个图表显示了原因。潜在的 USB 数据传输率差异 很大

 title=

图 8. USB 速度变化很大。(Howard Fosdick,根据 TrippliteWikipedia 提供的数字,CC BY-SA 4.0)

HardInfo 的“USB 设备”标签显示了你的计算机支持的 USB 标准。大多数计算机提供不止一种速度。你怎么知道一个特定端口的速度呢?供应商对它们进行颜色编码,如图表中所示。或者你可以在你的计算机的文档中查找。

要看到你得到的实际速度,可以使用开源的 GNOME 磁盘 程序进行测试。只要启动 GNOME 磁盘,选择它的“磁盘基准”功能,然后运行一个基准测试。这将告诉你在一个端口插入特定设备时,你将得到的最大实际速度。

你可能会得到不同的端口传输速度,这取决于你将哪个设备插入它。数据速率取决于端口和设备的特定组合。

例如,一个可以以 3.1 速度运行的设备如果使用 2.0 端口就会以 2.0 的速度运行。(而且它不会告诉你它是以较慢的速度运行的!)相反,如果你把一个 USB 2.0 设备插入 3.1 端口,它能工作,但速度是 2.0 的速度。所以要获得快速的 USB,你必须确保端口和设备都支持它。GNOME 磁盘为你提供了验证这一点的方法。

要确定 USB 的处理瓶颈,使用你对固态和硬盘所做的同样程序。运行 atop 命令来发现 USB 存储瓶颈。然后,使用系统监视器来获取违规进程的详细信息。

如何识别互联网带宽瓶颈

系统监控器的“资源”面板会实时告诉你互联网连接速度(见图 1)。

很好的 Python 工具 可以测试你的最大网速,但你也可以在 SpeedtestFast.comSpeakeasy 等网站进行测试。为了获得最佳结果,关闭所有东西,只运行 速度测试;关闭你的虚拟私有网络;在一天中的不同时间运行测试;并比较几个测试网站的结果。

然后将你的结果与你的供应商声称的下载和上传速度进行比较。这样,你就可以确认你得到的是你所付费的速度。

如果你有一个单独的路由器,在有和没有它的情况下进行测试。这可以告诉你,你的路由器是否是一个瓶颈。如果你使用 WiFi,在有 WiFi 和没有 WiFi 的情况下进行测试(通过将你的笔记本电脑直接与调制解调器连接)。我经常看到人们抱怨他们的互联网供应商,而实际上他们只是有一个 WiFi 瓶颈,可以自己解决。

如果某些程序正在消耗你的整个互联网连接,你想知道是哪一个。通过使用 nethogs 命令找到它。它在大多数软件库中都有。

有一天,我的系统监视器突然显示我的互联网访问量激增。我只是在命令行中输入了 nethogs,它立即确定带宽消耗者是 Clamav 防病毒更新。

 title=

图 9. Nethogs 识别带宽用户。(Howard Fosdick, CC BY-SA 4.0)

如何识别图形处理瓶颈

如果你把显示器插在台式电脑后面的主板上,你就在使用 板载显卡。如果你把它插在后面的卡上,你就有一个专门的图形子系统。大多数人称它为 视频卡显卡。对于台式电脑来说,附加显卡通常比主板上的显卡更强大、更昂贵。笔记本电脑总是使用板载显卡。

HardInfo 的“PCI 设备”面板告诉你关于你的图形处理单元(GPU)。它还显示你的专用视频内存的数量(寻找标有“可预取”的内存)。

 title=

图 10. HardInfo提供图形处理信息。(Howard Fosdick, CC BY-SA 4.0)

CPU 和 GPU 非常密切地 一起工作。简而言之,CPU 为 GPU 准备渲染的帧,然后 GPU 渲染这些帧。

当你的 CPU 在等待 100% 繁忙的 GPU 时,就会出现 GPU 瓶颈

为了确定这一点,你需要监控 CPU 和 GPU 的利用率。像 ConkyGlances 这样的开源监控器,如果它们的扩展插件支持你的图形芯片组,就可以做到这一点。

看一下 Conky 的这个例子。你可以看到,这个系统有很多可用的 CPU。GPU 只有 25% 的使用率。想象一下,如果这个 GPU 的数量接近 100%。那么你就会知道 CPU 在等待 GPU,你就会有一个 GPU 的瓶颈。

 title=

图 11. Conky 显示 CPU 和 GPU 的利用率。 (图片来源:AskUbuntu论坛)

在某些系统上,你需要一个供应商专属的工具来监控你的 GPU。它们可以从 GitHub 上下载,并在 GPU 监控和诊断命令行工具 这篇文章中有所描述。

总结

计算机由一系列集成的硬件资源组成。如果它们中的任何一个在工作量上远远落后于其他资源,就会产生性能瓶颈。这可能会拖累你的整个系统。你需要能够识别和纠正瓶颈,以实现最佳性能。

不久前,识别瓶颈需要深厚的专业知识。今天的开源 GUI 性能监控器使它变得相当简单。

在我的下一篇文章中,我将讨论改善你的 Linux 电脑性能的具体方法。同时,请在评论中分享你自己的经验。


via: https://opensource.com/article/21/3/linux-performance-bottlenecks

作者:Howard Fosdick 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

你知道在 Linux 中我们使用什么工具检修和监控实时的磁盘活动吗?如果 Linux 系统性能变慢,我们会用 top 命令 来查看系统性能。它被用来检查是什么进程在服务器上占有如此高的使用率,对于大多数 Linux 系统管理员来说很常见,现实世界中被 Linux 系统管理员广泛采用。

如果在进程输出中你没有看到很大的不同,你仍然有选择查看其他东西。我会建议你在 top 输出中检查 wa 状态,因为大多数时间里服务器性能由于在硬盘上的高 I/O 读和写降低了性能。如果它很高或者波动,很可能就是它造成的。因此,我们需要检查硬盘上的 I/O 活动。

我们可以在 Linux 中使用 iotopiostat 命令监控所有的磁盘和文件系统的磁盘 I/O 统计。

什么是 iotop?

iotop 是一个类似 top 的工具,用来显示实时的磁盘活动。

iotop 监控 Linux 内核输出的 I/O 使用信息,并且显示一个系统中进程或线程的当前 I/O 使用情况。

它显示每个进程/线程读写 I/O 带宽。它同样显示当等待换入和等待 I/O 的线程/进程花费的时间的百分比。

Total DISK READTotal DISK WRITE 的值一方面表示了进程和内核线程之间的总的读写带宽,另一方面也表示内核块设备子系统的。

Actual DISK READActual DISK WRITE 的值表示在内核块设备子系统和下面硬件(HDD、SSD 等等)对应的实际磁盘 I/O 带宽。

如何在 Linux 中安装 iotop ?

我们可以轻松在包管理器的帮助下安装,因为该软件包在所有的 Linux 发行版仓库中都可以获得。

对于 Fedora 系统,使用 DNF 命令 来安装 iotop

$ sudo dnf install iotop

对于 Debian/Ubuntu 系统,使用 API-GET 命令 或者 APT 命令 来安装 iotop

$ sudo apt install iotop

对于基于 Arch Linux 的系统,使用 Pacman Command 来安装 iotop

$ sudo pacman -S iotop

对于 RHEL/CentOS 的系统,使用 YUM Command 来安装 iotop

$ sudo yum install iotop

对于使用 openSUSE Leap 的系统,使用 Zypper Command 来安装 iotop

$ sudo zypper install iotop

在 Linux 中如何使用 iotop 命令来监控磁盘 I/O 活动/统计?

iotop 命令有很多参数来检查关于磁盘 I/O 的变化:

# iotop

10

如果你想检查那个进程实际在做 I/O,那么运行 iotop 命令加上 -o 或者 --only 参数。

# iotop --only

11

细节:

  • IO:它显示每个进程的 I/O 利用率,包含磁盘和交换。
  • SWAPIN: 它只显示每个进程的交换使用率。

什么是 iostat?

iostat 被用来报告中央处理单元(CPU)的统计和设备与分区的输出/输出的统计。

iostat 命令通过观察与它们平均传输率相关的设备活跃时间来监控系统输入/输出设备负载。

iostat 命令生成的报告可以被用来改变系统配置来更好的平衡物理磁盘之间的输入/输出负载。

所有的统计都在 iostat 命令每次运行时被报告。该报告包含一个 CPU 头部,后面是一行 CPU 统计。

在多处理器系统中,CPU 统计被计算为系统层面的所有处理器的平均值。设备头行后紧跟显示每个配置的设备一行的统计。

iostat 命令生成两种类型的报告,CPU 利用率报告和设备利用率报告。

在 Linux 中怎样安装 iostat?

iostat 工具是 sysstat 包的一部分,所以我们可以轻松地在包管理器地帮助下安装,因为在所有的 Linux 发行版的仓库都是可以获得的。

对于 Fedora 系统,使用 DNF Command 来安装 sysstat

$ sudo dnf install sysstat

对于 Debian/Ubuntu 系统,使用 APT-GET Command 或者 APT Command 来安装 sysstat

$ sudo apt install sysstat

对于基于 Arch Linux 的系统,使用 Pacman Command 来安装 sysstat

$ sudo pacman -S sysstat

对于 RHEL/CentOS 系统,使用 YUM Command 来安装 sysstat

$ sudo yum install sysstat

对于 openSUSE Leap 系统,使用 Zypper Command 来安装 sysstat

$ sudo zypper install sysstat

在 Linux 中如何使用 sysstat 命令监控磁盘 I/O 活动/统计?

iostat 命令中有很多参数来检查关于 I/O 和 CPU 的变化统计信息。

不加参数运行 iostat 命令会看到完整的系统统计。

# iostat

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.45    0.02   16.47    0.12    0.00   53.94

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1           6.68       126.95       124.97         0.00   58420014   57507206          0
sda               0.18         6.77        80.24         0.00    3115036   36924764          0
loop0             0.00         0.00         0.00         0.00       2160          0          0
loop1             0.00         0.00         0.00         0.00       1093          0          0
loop2             0.00         0.00         0.00         0.00       1077          0          0

运行 iostat 命令加上 -d 参数查看所有设备的 I/O 统计。

# iostat -d

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1           6.68       126.95       124.97         0.00   58420030   57509090          0
sda               0.18         6.77        80.24         0.00    3115292   36924764          0
loop0             0.00         0.00         0.00         0.00       2160          0          0
loop1             0.00         0.00         0.00         0.00       1093          0          0
loop2             0.00         0.00         0.00         0.00       1077          0          0

运行 iostat 命令加上 -p 参数查看所有的设备和分区的 I/O 统计。

# iostat -p

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.42    0.02   16.45    0.12    0.00   53.99

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1           6.68       126.94       124.96         0.00   58420062   57512278          0
nvme0n1p1         6.40       124.46       118.36         0.00   57279753   54474898          0
nvme0n1p2         0.27         2.47         6.60         0.00    1138069    3037380          0
sda               0.18         6.77        80.23         0.00    3116060   36924764          0
sda1              0.00         0.01         0.00         0.00       3224          0          0
sda2              0.18         6.76        80.23         0.00    3111508   36924764          0
loop0             0.00         0.00         0.00         0.00       2160          0          0
loop1             0.00         0.00         0.00         0.00       1093          0          0
loop2             0.00         0.00         0.00         0.00       1077          0          0

运行 iostat 命令加上 -x 参数显示所有设备的详细的 I/O 统计信息。

# iostat -x

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.41    0.02   16.45    0.12    0.00   54.00

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz  aqu-sz  %util
nvme0n1          2.45    126.93     0.60  19.74    0.40    51.74    4.23    124.96     5.12  54.76    3.16    29.54    0.00      0.00     0.00   0.00    0.00     0.00    0.31  30.28
sda              0.06      6.77     0.00   0.00    8.34   119.20    0.12     80.23    19.94  99.40   31.84   670.73    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.13
loop0            0.00      0.00     0.00   0.00    0.08    19.64    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.00
loop1            0.00      0.00     0.00   0.00    0.40    12.86    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.00
loop2            0.00      0.00     0.00   0.00    0.38    19.58    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00   0.00

运行 iostat 命令加上 -d [设备名] 参数查看具体设备和它的分区的 I/O 统计信息。

# iostat -p [Device_Name]

# iostat -p sda

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.38    0.02   16.43    0.12    0.00   54.05

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
sda               0.18         6.77        80.21         0.00    3117468   36924764          0
sda2              0.18         6.76        80.21         0.00    3112916   36924764          0
sda1              0.00         0.01         0.00         0.00       3224          0          0

运行 iostat 命令加上 -m 参数以 MB 为单位而不是 KB 查看所有设备的统计。默认以 KB 显示输出。

# iostat -m

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.36    0.02   16.41    0.12    0.00   54.09

Device             tps    MB_read/s    MB_wrtn/s    MB_dscd/s    MB_read    MB_wrtn    MB_dscd
nvme0n1           6.68         0.12         0.12         0.00      57050      56176          0
sda               0.18         0.01         0.08         0.00       3045      36059          0
loop0             0.00         0.00         0.00         0.00          2          0          0
loop1             0.00         0.00         0.00         0.00          1          0          0
loop2             0.00         0.00         0.00         0.00          1          0          0

运行 iostat 命令使用特定的间隔使用如下的格式。在这个例子中,我们打算以 5 秒捕获的间隔捕获两个报告。

# iostat [Interval] [Number Of Reports]

# iostat 5 2

Linux 4.19.32-1-MANJARO (daygeek-Y700)  Thursday 18 April 2019  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          29.35    0.02   16.41    0.12    0.00   54.10

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1           6.68       126.89       124.95         0.00   58420116   57525344          0
sda               0.18         6.77        80.20         0.00    3118492   36924764          0
loop0             0.00         0.00         0.00         0.00       2160          0          0
loop1             0.00         0.00         0.00         0.00       1093          0          0
loop2             0.00         0.00         0.00         0.00       1077          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.71    0.00    2.51    0.05    0.00   93.73

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1          19.00         0.20       311.40         0.00          1       1557          0
sda               0.20        25.60         0.00         0.00        128          0          0
loop0             0.00         0.00         0.00         0.00          0          0          0
loop1             0.00         0.00         0.00         0.00          0          0          0
loop2             0.00         0.00         0.00         0.00          0          0          0

运行 iostat 命令与 -N 参数来查看 LVM 磁盘 I/O 统计报告。

# iostat -N

Linux 4.15.0-47-generic (Ubuntu18.2daygeek.com)     Thursday 18 April 2019  _x86_64_    (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.38    0.07    0.18    0.26    0.00   99.12

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               3.60        57.07        69.06     968729    1172340
sdb               0.02         0.33         0.00       5680          0
sdc               0.01         0.12         0.00       2108          0
2g-2gvol1         0.00         0.07         0.00       1204          0

运行 nfsiostat 命令来查看 Network File System(NFS)的 I/O 统计。

# nfsiostat

via: https://www.2daygeek.com/check-monitor-disk-io-in-linux-using-iotop-iostat-command/

作者:Magesh Maruthamuthu 选题:lujun9972 译者:warmfrog 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Anthony Starks 使用他出色的 Deck 演示工具重构了我原来的基于 Google Slides 的幻灯片。你可以在他的博客上查看他重构后的幻灯片,
mindchunk.blogspot.com.au/2014/06/remixing-with-deck

我最近被邀请在 Gocon 发表演讲,这是一个每半年在日本东京举行的 Go 的精彩大会。Gocon 2014 是一个完全由社区驱动的为期一天的活动,由培训和一整个下午的围绕着生产环境中的 Go 这个主题的演讲组成.(LCTT 译注:本文发表于 2014 年)

以下是我的讲义。原文的结构能让我缓慢而清晰的演讲,因此我已经编辑了它使其更可读。

我要感谢 Bill Kennedy 和 Minux Ma,特别是 Josh Bleecher Snyder,感谢他们在我准备这次演讲中的帮助。


大家下午好。

我叫 David.

我很高兴今天能来到 Gocon。我想参加这个会议已经两年了,我很感谢主办方能提供给我向你们演讲的机会。

Gocon 2014

我想以一个问题开始我的演讲。

为什么选择 Go?

当大家讨论学习或在生产环境中使用 Go 的原因时,答案不一而足,但因为以下三个原因的最多。

Gocon 2014

这就是 TOP3 的原因。

第一,并发。

Go 的 并发原语 Concurrency Primitives 对于来自 Nodejs,Ruby 或 Python 等单线程脚本语言的程序员,或者来自 C++ 或 Java 等重量级线程模型的语言都很有吸引力。

易于部署。

我们今天从经验丰富的 Gophers 那里听说过,他们非常欣赏部署 Go 应用的简单性。

Gocon 2014

然后是性能。

我相信人们选择 Go 的一个重要原因是它 快。

Gocon 2014 (4)

在今天的演讲中,我想讨论五个有助于提高 Go 性能的特性。

我还将与大家分享 Go 如何实现这些特性的细节。

Gocon 2014 (5)

我要谈的第一个特性是 Go 对于值的高效处理和存储。

Gocon 2014 (6)

这是 Go 中一个值的例子。编译时,gocon 正好消耗四个字节的内存。

让我们将 Go 与其他一些语言进行比较

Gocon 2014 (7)

由于 Python 表示变量的方式的开销,使用 Python 存储相同的值会消耗六倍的内存。

Python 使用额外的内存来跟踪类型信息,进行 引用计数 Reference Counting 等。

让我们看另一个例子:

Gocon 2014 (8)

与 Go 类似,Java 消耗 4 个字节的内存来存储 int 型。

但是,要在像 ListMap 这样的集合中使用此值,编译器必须将其转换为 Integer 对象。

Gocon 2014 (9)

因此,Java 中的整数通常消耗 16 到 24 个字节的内存。

为什么这很重要? 内存便宜且充足,为什么这个开销很重要?

Gocon 2014 (10)

这是一张显示 CPU 时钟速度与内存总线速度的图表。

请注意 CPU 时钟速度和内存总线速度之间的差距如何继续扩大。

两者之间的差异实际上是 CPU 花费多少时间等待内存。

Gocon 2014 (11)

自 1960 年代后期以来,CPU 设计师已经意识到了这个问题。

他们的解决方案是一个缓存,一个更小、更快的内存区域,介入 CPU 和主存之间。

Gocon 2014 (12)

这是一个 Location 类型,它保存物体在三维空间中的位置。它是用 Go 编写的,因此每个 Location 只消耗 24 个字节的存储空间。

我们可以使用这种类型来构造一个容纳 1000 个 Location 的数组类型,它只消耗 24000 字节的内存。

在数组内部,Location 结构体是顺序存储的,而不是随机存储的 1000 个 Location 结构体的指针。

这很重要,因为现在所有 1000 个 Location 结构体都按顺序放在缓存中,紧密排列在一起。

Gocon 2014 (13)

Go 允许您创建紧凑的数据结构,避免不必要的填充字节。

紧凑的数据结构能更好地利用缓存。

更好的缓存利用率可带来更好的性能。

Gocon 2014 (14)

函数调用不是无开销的。

Gocon 2014 (15)

调用函数时会发生三件事。

创建一个新的 栈帧 Stack Frame ,并记录调用者的详细信息。

在函数调用期间可能被覆盖的任何寄存器都将保存到栈中。

处理器计算函数的地址并执行到该新地址的分支。

Gocon 2014 (16)

由于函数调用是非常常见的操作,因此 CPU 设计师一直在努力优化此过程,但他们无法消除开销。

函调固有开销,或重于泰山,或轻于鸿毛,这取决于函数做了什么。

减少函数调用开销的解决方案是 内联 Inlining

Gocon 2014 (17)

Go 编译器通过将函数体视为调用者的一部分来内联函数。

内联也有成本,它增加了二进制文件大小。

只有当调用开销与函数所做工作关联度的很大时内联才有意义,因此只有简单的函数才能用于内联。

复杂的函数通常不受调用它们的开销所支配,因此不会内联。

Gocon 2014 (18)

这个例子显示函数 Double 调用 util.Max

为了减少调用 util.Max 的开销,编译器可以将 util.Max 内联到 Double 中,就象这样

Gocon 2014 (19)

内联后不再调用 util.Max,但是 Double 的行为没有改变。

内联并不是 Go 独有的。几乎每种编译或及时编译的语言都执行此优化。但是 Go 的内联是如何实现的?

Go 实现非常简单。编译包时,会标记任何适合内联的小函数,然后照常编译。

然后函数的源代码和编译后版本都会被存储。

Gocon 2014 (20)

此幻灯片显示了 util.a 的内容。源代码已经过一些转换,以便编译器更容易快速处理。

当编译器编译 Double 时,它看到 util.Max 可内联的,并且 util.Max 的源代码是可用的。

就会替换原函数中的代码,而不是插入对 util.Max 的编译版本的调用。

拥有该函数的源代码可以实现其他优化。

Gocon 2014 (21)

在这个例子中,尽管函数 Test 总是返回 false,但 Expensive 在不执行它的情况下无法知道结果。

Test 被内联时,我们得到这样的东西。

Gocon 2014 (22)

编译器现在知道 Expensive 的代码无法访问。

这不仅节省了调用 Test 的成本,还节省了编译或运行任何现在无法访问的 Expensive 代码。

Go 编译器可以跨文件甚至跨包自动内联函数。还包括从标准库调用的可内联函数的代码。

Gocon 2014 (23)

强制垃圾回收 Mandatory Garbage Collection 使 Go 成为一种更简单,更安全的语言。

这并不意味着垃圾回收会使 Go 变慢,或者垃圾回收是程序速度的瓶颈。

这意味着在堆上分配的内存是有代价的。每次 GC 运行时都会花费 CPU 时间,直到释放内存为止。

Gocon 2014 (24)

然而,有另一个地方分配内存,那就是栈。

与 C 不同,它强制您选择是否将值通过 malloc 将其存储在堆上,还是通过在函数范围内声明将其储存在栈上;Go 实现了一个名为 逃逸分析 Escape Analysis 的优化。

Gocon 2014 (25)

逃逸分析决定了对一个值的任何引用是否会从被声明的函数中逃逸。

如果没有引用逃逸,则该值可以安全地存储在栈中。

存储在栈中的值不需要分配或释放。

让我们看一些例子

Gocon 2014 (26)

Sum 返回 1 到 100 的整数的和。这是一种相当不寻常的做法,但它说明了逃逸分析的工作原理。

因为切片 numbers 仅在 Sum 内引用,所以编译器将安排到栈上来存储的 100 个整数,而不是安排到堆上。

没有必要回收 numbers,它会在 Sum 返回时自动释放。

Gocon 2014 (27)

第二个例子也有点尬。在 CenterCursor 中,我们创建一个新的 Cursor 对象并在 c 中存储指向它的指针。

然后我们将 c 传递给 Center() 函数,它将 Cursor 移动到屏幕的中心。

最后我们打印出那个 ‘Cursor` 的 X 和 Y 坐标。

即使 cnew 函数分配了空间,它也不会存储在堆上,因为没有引用 c 的变量逃逸 CenterCursor 函数。

Gocon 2014 (28)

默认情况下,Go 的优化始终处于启用状态。可以使用 -gcflags = -m 开关查看编译器的逃逸分析和内联决策。

因为逃逸分析是在编译时执行的,而不是运行时,所以无论垃圾回收的效率如何,栈分配总是比堆分配快。

我将在本演讲的其余部分详细讨论栈。

Gocon 2014 (30)

Go 有 goroutine。 这是 Go 并发的基石。

我想退一步,探索 goroutine 的历史。

最初,计算机一次运行一个进程。在 60 年代,多进程或 分时 Time Sharing 的想法变得流行起来。

在分时系统中,操作系统必须通过保护当前进程的现场,然后恢复另一个进程的现场,不断地在这些进程之间切换 CPU 的注意力。

这称为 进程切换。

Gocon 2014 (29)

进程切换有三个主要开销。

首先,内核需要保护该进程的所有 CPU 寄存器的现场,然后恢复另一个进程的现场。

内核还需要将 CPU 的映射从虚拟内存刷新到物理内存,因为这些映射仅对当前进程有效。

最后是操作系统 上下文切换 Context Switch 的成本,以及 调度函数 Scheduler Function 选择占用 CPU 的下一个进程的开销。

Gocon 2014 (31)

现代处理器中有数量惊人的寄存器。我很难在一张幻灯片上排开它们,这可以让你知道保护和恢复它们需要多少时间。

由于进程切换可以在进程执行的任何时刻发生,因此操作系统需要存储所有寄存器的内容,因为它不知道当前正在使用哪些寄存器。

Gocon 2014 (32)

这导致了线程的出生,这些线程在概念上与进程相同,但共享相同的内存空间。

由于线程共享地址空间,因此它们比进程更轻,因此创建速度更快,切换速度更快。

Gocon 2014 (33)

Goroutine 升华了线程的思想。

Goroutine 是 协作式调度 Cooperative Scheduled <br/> 的,而不是依靠内核来调度。

当对 Go 运行时调度器 Runtime Scheduler 进行显式调用时,goroutine 之间的切换仅发生在明确定义的点上。

编译器知道正在使用的寄存器并自动保存它们。

Gocon 2014 (34)

虽然 goroutine 是协作式调度的,但运行时会为你处理。

Goroutine 可能会给禅让给其他协程时刻是:

  • 阻塞式通道发送和接收。
  • Go 声明,虽然不能保证会立即调度新的 goroutine。
  • 文件和网络操作式的阻塞式系统调用。
  • 在被垃圾回收循环停止后。

Gocon 2014 (35)

这个例子说明了上一张幻灯片中描述的一些调度点。

箭头所示的线程从左侧的 ReadFile 函数开始。遇到 os.Open,它在等待文件操作完成时阻塞线程,因此调度器将线程切换到右侧的 goroutine。

继续执行直到从通道 c 中读,并且此时 os.Open 调用已完成,因此调度器将线程切换回左侧并继续执行 file.Read 函数,然后又被文件 IO 阻塞。

调度器将线程切换回右侧以进行另一个通道操作,该操作在左侧运行期间已解锁,但在通道发送时再次阻塞。

最后,当 Read 操作完成并且数据可用时,线程切换回左侧。

Gocon 2014 (36)

这张幻灯片显示了低级语言描述的 runtime.Syscall 函数,它是 os 包中所有函数的基础。

只要你的代码调用操作系统,就会通过此函数。

entersyscall 的调用通知运行时该线程即将阻塞。

这允许运行时启动一个新线程,该线程将在当前线程被阻塞时为其他 goroutine 提供服务。

这导致每 Go 进程的操作系统线程相对较少,Go 运行时负责将可运行的 Goroutine 分配给空闲的操作系统线程。

Gocon 2014 (37)

在上一节中,我讨论了 goroutine 如何减少管理许多(有时是数十万个并发执行线程)的开销。

Goroutine故事还有另一面,那就是栈管理,它引导我进入我的最后一个话题。

Gocon 2014 (39)

这是一个进程的内存布局图。我们感兴趣的关键是堆和栈的位置。

传统上,在进程的地址空间内,堆位于内存的底部,位于程序(代码)的上方并向上增长。

栈位于虚拟地址空间的顶部,并向下增长。

Gocon 2014 (40)

因为堆和栈相互覆盖的结果会是灾难性的,操作系统通常会安排在栈和堆之间放置一个不可写内存区域,以确保如果它们发生碰撞,程序将中止。

这称为保护页,有效地限制了进程的栈大小,通常大约为几兆字节。

Gocon 2014 (41)

我们已经讨论过线程共享相同的地址空间,因此对于每个线程,它必须有自己的栈。

由于很难预测特定线程的栈需求,因此为每个线程的栈和保护页面保留了大量内存。

希望是这些区域永远不被使用,而且防护页永远不会被击中。

缺点是随着程序中线程数的增加,可用地址空间的数量会减少。

Gocon 2014 (42)

我们已经看到 Go 运行时将大量的 goroutine 调度到少量线程上,但那些 goroutines 的栈需求呢?

Go 编译器不使用保护页,而是在每个函数调用时插入一个检查,以检查是否有足够的栈来运行该函数。如果没有,运行时可以分配更多的栈空间。

由于这种检查,goroutines 初始栈可以做得更小,这反过来允许 Go 程序员将 goroutines 视为廉价资源。

Gocon 2014 (43)

这是一张显示了 Go 1.2 如何管理栈的幻灯片。

G 调用 H 时,没有足够的空间让 H 运行,所以运行时从堆中分配一个新的栈帧,然后在新的栈段上运行 H。当 H 返回时,栈区域返回到堆,然后返回到 G

Gocon 2014 (44)

这种管理栈的方法通常很好用,但对于某些类型的代码,通常是递归代码,它可能导致程序的内部循环跨越这些栈边界之一。

例如,在程序的内部循环中,函数 G 可以在循环中多次调用 H

每次都会导致栈拆分。 这被称为 热分裂 Hot Split 问题。

Gocon 2014 (45)

为了解决热分裂问题,Go 1.3 采用了一种新的栈管理方法。

如果 goroutine 的栈太小,则不会添加和删除其他栈段,而是分配新的更大的栈。

旧栈的内容被复制到新栈,然后 goroutine 使用新的更大的栈继续运行。

在第一次调用 H 之后,栈将足够大,对可用栈空间的检查将始终成功。

这解决了热分裂问题。

Gocon 2014 (46)

值,内联,逃逸分析,Goroutines 和分段/复制栈。

这些是我今天选择谈论的五个特性,但它们绝不是使 Go 成为快速的语言的唯一因素,就像人们引用他们学习 Go 的理由的三个原因一样。

这五个特性一样强大,它们不是孤立存在的。

例如,运行时将 goroutine 复用到线程上的方式在没有可扩展栈的情况下几乎没有效率。

内联通过将较小的函数组合成较大的函数来降低栈大小检查的成本。

逃逸分析通过自动将从实例从堆移动到栈来减少垃圾回收器的压力。

逃逸分析还提供了更好的 缓存局部性 Cache Locality

如果没有可增长的栈,逃逸分析可能会对栈施加太大的压力。

Gocon 2014 (47)

  • 感谢 Gocon 主办方允许我今天发言
  • twitter / web / email details
  • 感谢 @offbymany,@billkennedy\_go 和 Minux 在准备这个演讲的过程中所提供的帮助。

相关文章:

  1. 听我在 OSCON 上关于 Go 性能的演讲
  2. 为什么 Goroutine 的栈是无限大的?
  3. Go 的运行时环境变量的旋风之旅
  4. 没有事件循环的性能

作者简介:

David 是来自澳大利亚悉尼的程序员和作者。

自 2011 年 2 月起成为 Go 的 contributor,自 2012 年 4 月起成为 committer。

联系信息


via: https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast

作者:Dave Cheney 译者:houbaron 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

了解应用程序的输入/输出(I/O)模型意味着理解应用程序处理其数据的载入差异,并揭示其在真实环境中表现。或许你的应用程序很小,在不承受很大的负载时,这并不是个严重的问题;但随着应用程序的流量负载增加,可能因为使用了低效的 I/O 模型导致承受不了而崩溃。

和大多数情况一样,处理这种问题的方法有多种方式,这不仅仅是一个择优的问题,而是对权衡的理解问题。 接下来我们来看看 I/O 到底是什么。

Cover Photo: Server-side I/O: Node vs. PHP vs. Java vs. Go

在本文中,我们将对 Node、Java、Go 和 PHP + Apache 进行对比,讨论不同语言如何构造其 I/O ,每个模型的优缺点,并总结一些基本的规律。如果你担心你的下一个 Web 应用程序的 I/O 性能,本文将给你最优的解答。

I/O 基础知识: 快速复习

要了解 I/O 所涉及的因素,我们首先深入到操作系统层面复习这些概念。虽然看起来并不与这些概念直接打交道,但你会一直通过应用程序的运行时环境与它们间接接触。了解细节很重要。

系统调用

首先是系统调用,其被描述如下:

  • 程序(所谓“ 用户端 user land ”)必须请求操作系统内核代表它执行 I/O 操作。
  • 系统调用 syscall ”是你的程序要求内核执行某些操作的方法。这些实现的细节在操作系统之间有所不同,但基本概念是相同的。有一些具体的指令会将控制权从你的程序转移到内核(类似函数调用,但是使用专门用于处理这种情况的专用方式)。一般来说,系统调用会被阻塞,这意味着你的程序会等待内核返回(控制权到)你的代码。
  • 内核在所需的物理设备( 磁盘、网卡等 )上执行底层 I/O 操作,并回应系统调用。在实际情况中,内核可能需要做许多事情来满足你的要求,包括等待设备准备就绪、更新其内部状态等,但作为应用程序开发人员,你不需要关心这些。这是内核的工作。

Syscalls Diagram

阻塞与非阻塞

上面我们提到过,系统调用是阻塞的,一般来说是这样的。然而,一些调用被归类为“非阻塞”,这意味着内核会接收你的请求,将其放在队列或缓冲区之类的地方,然后立即返回而不等待实际的 I/O 发生。所以它只是在很短的时间内“阻塞”,只需要排队你的请求即可。

举一些 Linux 系统调用的例子可能有助于理解:

  • read() 是一个阻塞调用 - 你传递一个句柄,指出哪个文件和缓冲区在哪里传送它所读取的数据,当数据就绪时,该调用返回。这种方式的优点是简单友好。
  • 分别调用 epoll_create()epoll_ctl()epoll_wait() ,你可以创建一组句柄来侦听、添加/删除该组中的处理程序、然后阻塞直到有任何事件发生。这允许你通过单个线程有效地控制大量的 I/O 操作,但是现在谈这个还太早。如果你需要这个功能当然好,但须知道它使用起来是比较复杂的。

了解这里的时间差异的数量级是很重要的。假设 CPU 内核运行在 3GHz,在没有进行 CPU 优化的情况下,那么它每秒执行 30 亿次 周期 cycle (即每纳秒 3 个周期)。非阻塞系统调用可能需要几十个周期来完成,或者说 “相对少的纳秒” 时间完成。而一个被跨网络接收信息所阻塞的系统调用可能需要更长的时间 - 例如 200 毫秒(1/5 秒)。这就是说,如果非阻塞调用需要 20 纳秒,阻塞调用需要 2 亿纳秒。你的进程因阻塞调用而等待了 1000 万倍的时长!

Blocking vs. Non-blocking Syscalls

内核既提供了阻塞 I/O (“从网络连接读取并给出数据”),也提供了非阻塞 I/O (“告知我何时这些网络连接具有新数据”)的方法。使用的是哪种机制对调用进程的阻塞时长有截然不同的影响。

调度

关键的第三件事是当你有很多线程或进程开始阻塞时会发生什么。

根据我们的理解,线程和进程之间没有很大的区别。在现实生活中,最显著的性能相关的差异在于,由于线程共享相同的内存,而进程每个都有自己的内存空间,使得单独的进程往往占用更多的内存。但是当我们谈论 调度 Scheduling 时,它真正归结为一类事情(线程和进程类同),每个都需要在可用的 CPU 内核上获得一段执行时间。如果你有 300 个线程运行在 8 个内核上,则必须将时间分成几份,以便每个线程和进程都能分享它,每个运行一段时间,然后交给下一个。这是通过 “ 上下文切换 context switch ” 完成的,可以使 CPU 从运行到一个线程/进程到切换下一个。

这些上下文切换也有相关的成本 - 它们需要一些时间。在某些快速的情况下,它可能小于 100 纳秒,但根据实际情况、处理器速度/体系结构、CPU 缓存等,偶见花费 1000 纳秒或更长时间。

而线程(或进程)越多,上下文切换就越多。当我们涉及数以千计的线程时,每个线程花费数百纳秒,就会变得很慢。

然而,非阻塞调用实质上是告诉内核“仅在这些连接之一有新的数据或事件时再叫我”。这些非阻塞调用旨在有效地处理大量 I/O 负载并减少上下文交换。

这些你明白了么?现在来到了真正有趣的部分:我们来看看一些流行的语言对那些工具的使用,并得出关于易用性和性能之间权衡的结论,以及一些其他有趣小东西。

声明,本文中显示的示例是零碎的(片面的,只能体现相关的信息); 数据库访问、外部缓存系统( memcache 等等)以及任何需要 I/O 的东西都将执行某种类型的 I/O 调用,其实质与上面所示的简单示例效果相同。此外,对于将 I/O 描述为“阻塞”( PHP、Java )的情况,HTTP 请求和响应读取和写入本身就是阻塞调用:系统中隐藏着更多 I/O 及其伴生的性能问题需要考虑。

为一个项目选择编程语言要考虑很多因素。甚至当你只考虑效率时,也有很多因素。但是,如果你担心你的程序将主要受到 I/O 的限制,如果 I/O 性能影响到项目的成败,那么这些是你需要了解的。

“保持简单”方法:PHP

早在 90 年代,很多人都穿着 Converse 鞋,用 Perl 写着 CGI 脚本。然后 PHP 来了,就像一些人喜欢咒骂的一样,它使得动态网页更容易。

PHP 使用的模型相当简单。虽有一些出入,但你的 PHP 服务器基本上是这样:

HTTP 请求来自用户的浏览器,并访问你的 Apache Web 服务器。Apache 为每个请求创建一个单独的进程,有一些优化方式可以重新使用它们,以最大限度地减少创建次数( 相对而言,创建进程较慢 )。Apache 调用 PHP 并告诉它运行磁盘上合适的 .php 文件。PHP 代码执行并阻塞 I/O 调用。你在 PHP 中调用 file_get_contents() ,其底层会调用 read() 系统调用并等待结果。

当然,实际的代码是直接嵌入到你的页面,并且该操作被阻塞:

<?php

// blocking file I/O
$file_data = file_get_contents(‘/path/to/file.dat’);

// blocking network I/O
$curl = curl_init('http://example.com/example-microservice');
$result = curl_exec($curl);

// some more blocking network I/O
$result = $db->query('SELECT id, data FROM examples ORDER BY id DESC limit 100');

?>

关于如何与系统集成,就像这样:

I/O Model PHP

很简单:每个请求一个进程。 I/O 调用就阻塞。优点是简单可工作,缺点是,同时与 20,000 个客户端连接,你的服务器将会崩溃。这种方法不能很好地扩展,因为内核提供的用于处理大容量 I/O (epoll 等) 的工具没有被使用。 雪上加霜的是,为每个请求运行一个单独的进程往往会使用大量的系统资源,特别是内存,这通常是你在这样的场景中遇到的第一个问题。

注意:Ruby 使用的方法与 PHP 非常相似,在大致的方面上,它们可以被认为是相同的。

多线程方法: Java

就在你购买你的第一个域名,在某个句子后很酷地随机说出 “dot com” 的那个时候,Java 来了。而 Java 具有内置于该语言中的多线程功能,它非常棒(特别是在创建时)。

大多数 Java Web 服务器通过为每个请求启动一个新的执行线程,然后在该线程中最终调用你(作为应用程序开发人员)编写的函数。

在 Java Servlet 中执行 I/O 往往看起来像:

public void doGet(HttpServletRequest request,
    HttpServletResponse response) throws ServletException, IOException
{

    // blocking file I/O
    InputStream fileIs = new FileInputStream("/path/to/file");

    // blocking network I/O
    URLConnection urlConnection = (new URL("http://example.com/example-microservice")).openConnection();
    InputStream netIs = urlConnection.getInputStream();

    // some more blocking network I/O
out.println("...");
}

由于我们上面的 doGet 方法对应于一个请求,并且在其自己的线程中运行,而不是每个请求一个单独的进程,申请自己的内存。这样有一些好处,比如在线程之间共享状态、缓存数据等,因为它们可以访问彼此的内存,但是它与调度的交互影响与之前的 PHP 的例子几乎相同。每个请求获得一个新线程,该线程内的各种 I/O 操作阻塞在线程内,直到请求被完全处理为止。线程被池化以最小化创建和销毁它们的成本,但是数千个连接仍然意味着数千个线程,这对调度程序是不利的。

重要的里程碑出现在 Java 1.4 版本(以及 1.7 的重要升级)中,它获得了执行非阻塞 I/O 调用的能力。大多数应用程序、web 应用和其它用途不会使用它,但至少它是可用的。一些 Java Web 服务器尝试以各种方式利用这一点;然而,绝大多数部署的 Java 应用程序仍然如上所述工作。

I/O Model Java

肯定有一些很好的开箱即用的 I/O 功能,Java 让我们更接近,但它仍然没有真正解决当你有一个大量的 I/O 绑定的应用程序被数千个阻塞线程所压垮的问题。

无阻塞 I/O 作为一等公民: Node

当更好的 I/O 模式来到 Node.js,阻塞才真正被解决。任何一个曾听过 Node 简单介绍的人都被告知这是“非阻塞”,可以有效地处理 I/O。这在一般意义上是正确的。但在细节中则不尽然,而且当在进行性能工程时,这种巫术遇到了问题。

Node 实现的范例基本上不是说 “在这里写代码来处理请求”,而是说 “在这里写代码来开始处理请求”。每次你需要做一些涉及到 I/O 的操作,你会创建一个请求并给出一个回调函数,Node 将在完成之后调用该函数。

在请求中执行 I/O 操作的典型 Node 代码如下所示:

http.createServer(function(request, response) {
    fs.readFile('/path/to/file', 'utf8', function(err, data) {
        response.end(data);
    });
});

你可以看到,这里有两个回调函数。当请求开始时,第一个被调用,当文件数据可用时,第二个被调用。

这样做的基本原理是让 Node 有机会有效地处理这些回调之间的 I/O 。一个更加密切相关的场景是在 Node 中进行数据库调用,但是我不会在这个例子中啰嗦,因为它遵循完全相同的原则:启动数据库调用,并给 Node 一个回调函数,它使用非阻塞调用单独执行 I/O 操作,然后在你要求的数据可用时调用回调函数。排队 I/O 调用和让 Node 处理它然后获取回调的机制称为“事件循环”。它工作的很好。

I/O Model Node.js

然而,这个模型有一个陷阱,究其原因,很多是与 V8 JavaScript 引擎(Node 用的是 Chrome 浏览器的 JS 引擎)如何实现的有关 注1 。你编写的所有 JS 代码都运行在单个线程中。你可以想想,这意味着当使用高效的非阻塞技术执行 I/O 时,你的 JS 可以在单个线程中运行计算密集型的操作,每个代码块都会阻塞下一个。可能出现这种情况的一个常见例子是以某种方式遍历数据库记录,然后再将其输出到客户端。这是一个示例,展示了其是如何工作:

var handler = function(request, response) {

    connection.query('SELECT ...', function (err, rows) {

        if (err) { throw err };

        for (var i = 0; i < rows.length; i++) {
            // do processing on each row
        }

        response.end(...); // write out the results

    })

};

虽然 Node 确实有效地处理了 I/O ,但是上面的例子中 for 循环是在你的唯一的一个主线程中占用 CPU 周期。这意味着如果你有 10,000 个连接,则该循环可能会使你的整个应用程序像爬行般缓慢,具体取决于其会持续多久。每个请求必须在主线程中分享一段时间,一次一段。

这整个概念的前提是 I/O 操作是最慢的部分,因此最重要的是要有效地处理这些操作,即使这意味着要连续进行其他处理。这在某些情况下是正确的,但不是全部。

另一点是,虽然这只是一个观点,但是写一堆嵌套的回调可能是相当令人讨厌的,有些则认为它使代码更难以追踪。在 Node 代码中看到回调嵌套 4 层、5 层甚至更多层并不罕见。

我们再次来权衡一下。如果你的主要性能问题是 I/O,则 Node 模型工作正常。然而,它的关键是,你可以在一个处理 HTTP 请求的函数里面放置 CPU 密集型的代码,而且不小心的话会导致每个连接都很慢。

最自然的非阻塞:Go

在我进入 Go 部分之前,我应该披露我是一个 Go 的粉丝。我已经在许多项目中使用过它,我是一个其生产力优势的公开支持者,我在我的工作中使用它。

那么,让我们来看看它是如何处理 I/O 的。Go 语言的一个关键特征是它包含自己的调度程序。在 Go 中,不是每个执行线程对应于一个单一的 OS 线程,其通过一种叫做 “ 协程 goroutine ” 的概念来工作。而 Go 的运行时可以将一个协程分配给一个 OS 线程,使其执行或暂停它,并且它不与一个 OS 线程相关联——这要基于那个协程正在做什么。来自 Go 的 HTTP 服务器的每个请求都在单独的协程中处理。

调度程序的工作原理如图所示:

I/O Model Go

在底层,这是通过 Go 运行时中的各个部分实现的,它通过对请求的写入/读取/连接等操作来实现 I/O 调用,将当前协程休眠,并当采取进一步动作时唤醒该协程。

从效果上看,Go 运行时做的一些事情与 Node 做的没有太大不同,除了回调机制是内置到 I/O 调用的实现中,并自动与调度程序交互。它也不会受到必须让所有处理程序代码在同一个线程中运行的限制,Go 将根据其调度程序中的逻辑自动将协程映射到其认为适当的 OS 线程。结果是这样的代码:

func ServeHTTP(w http.ResponseWriter, r *http.Request) {

    // the underlying network call here is non-blocking
    rows, err := db.Query("SELECT ...")

    for _, row := range rows {
        // do something with the rows,
// each request in its own goroutine
    }

    w.Write(...) // write the response, also non-blocking

}

如上所述,我们重构基本的代码结构为更简化的方式,并在底层仍然实现了非阻塞 I/O。

在大多数情况下,最终是“两全其美”的。非阻塞 I/O 用于所有重要的事情,但是你的代码看起来像是阻塞,因此更容易理解和维护。Go 调度程序和 OS 调度程序之间的交互处理其余部分。这不是完整的魔法,如果你建立一个大型系统,那么值得我们来看看有关它的工作原理的更多细节;但与此同时,你获得的“开箱即用”的环境可以很好地工作和扩展。

Go 可能有其缺点,但一般来说,它处理 I/O 的方式不在其中。

谎言,可恶的谎言和基准

对这些各种模式的上下文切换进行准确的定时是很困难的。我也可以认为这对你来说不太有用。相反,我会给出一些比较这些服务器环境的整个 HTTP 服务器性能的基本基准。请记住,影响整个端到端 HTTP 请求/响应路径的性能有很多因素,这里提供的数字只是我将一些样本放在一起进行基本比较的结果。

对于这些环境中的每一个,我写了适当的代码在一个 64k 文件中读取随机字节,在其上运行了一个 SHA-256 哈希 N 次( N 在 URL 的查询字符串中指定,例如 .../test.php?n=100),并打印出结果十六进制散列。我选择这样做,是因为使用一些一致的 I/O 和受控的方式来运行相同的基准测试是一个增加 CPU 使用率的非常简单的方法。

有关使用的环境的更多细节,请参阅 基准说明

首先,我们来看一些低并发的例子。运行 2000 次迭代,300 个并发请求,每个请求只有一个散列(N = 1),结果如下:

Mean number of milliseconds to complete a request across all concurrent requests, N=1

时间是在所有并发请求中完成请求的平均毫秒数。越低越好。

仅从一张图很难得出结论,但是对我来说,似乎在大量的连接和计算量上,我们看到时间更多地与语言本身的一般执行有关,对于 I/O 更是如此。请注意,那些被视为“脚本语言”的语言(松散类型,动态解释)执行速度最慢。

但是,如果我们将 N 增加到 1000,仍然有 300 个并发请求,相同的任务,但是哈希迭代是 1000 倍(显着增加了 CPU 负载):

Mean number of milliseconds to complete a request across all concurrent requests, N=1000

时间是在所有并发请求中完成请求的平均毫秒数。越低越好。

突然间, Node 性能显著下降,因为每个请求中的 CPU 密集型操作都相互阻塞。有趣的是,在这个测试中,PHP 的性能要好得多(相对于其他的),并且打败了 Java。(值得注意的是,在 PHP 中,SHA-256 实现是用 C 编写的,在那个循环中执行路径花费了更多的时间,因为现在我们正在进行 1000 个哈希迭代)。

现在让我们尝试 5000 个并发连接(N = 1) - 或者是我可以发起的最大连接。不幸的是,对于大多数这些环境,故障率并不显着。对于这个图表,我们来看每秒的请求总数。 越高越好 :

Total number of requests per second, N=1, 5000 req/sec

每秒请求数。越高越好。

这个图看起来有很大的不同。我猜测,但是看起来像在高连接量时,产生新进程所涉及的每连接开销以及与 PHP + Apache 相关联的附加内存似乎成为主要因素,并阻止了 PHP 的性能。显然,Go 是这里的赢家,其次是 Java,Node,最后是 PHP。

虽然与你的整体吞吐量相关的因素很多,并且在应用程序之间也有很大的差异,但是你对底层发生什么的事情以及所涉及的权衡了解更多,你将会得到更好的结果。

总结

以上所有这一切,很显然,随着语言的发展,处理大量 I/O 的大型应用程序的解决方案也随之发展。

为了公平起见,PHP 和 Java,尽管这篇文章中的描述,确实 实现了web 应用程序可使用的 非阻塞 I/O 。但是这些方法并不像上述方法那么常见,并且需要考虑使用这种方法来维护服务器的随之而来的操作开销。更不用说你的代码必须以与这些环境相适应的方式进行结构化;你的 “正常” PHP 或 Java Web 应用程序通常不会在这样的环境中进行重大修改。

作为比较,如果我们考虑影响性能和易用性的几个重要因素,我们得出以下结论:

语言线程与进程非阻塞 I/O使用便捷性
PHP进程
Java线程可用需要回调
Node.js线程需要回调
Go线程 (协程)不需要回调

线程通常要比进程有更高的内存效率,因为它们共享相同的内存空间,而进程则没有。结合与非阻塞 I/O 相关的因素,我们可以看到,至少考虑到上述因素,当我们从列表往下看时,与 I/O 相关的一般设置得到改善。所以如果我不得不在上面的比赛中选择一个赢家,那肯定会是 Go。

即使如此,在实践中,选择构建应用程序的环境与你的团队对所述环境的熟悉程度以及你可以实现的总体生产力密切相关。因此,每个团队都深入并开始在 Node 或 Go 中开发 Web 应用程序和服务可能就没有意义。事实上,寻找开发人员或你内部团队的熟悉度通常被认为是不使用不同语言和/或环境的主要原因。也就是说,过去十五年来,时代已经发生了变化。

希望以上内容可以帮助你更清楚地了解底层发生的情况,并为你提供如何处理应用程序的现实可扩展性的一些想法。


via: https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go

作者:BRAD PEABODY 译者:MonkeyDEcho 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

应用程序的性能决定了软件能多快完成预期任务。这回答有关应用程序的几个问题,例如:

  • 峰值负载下的响应时间
  • 与替代方案相比,它易于使用,受支持的功能和用例
  • 运营成本(CPU 使用率、内存需求、数据吞吐量、带宽等)

该性能分析的价值超出了服务负载所需的计算资源或满足峰值需求所需的应用实例数量的估计。性能显然与成功企业的基本要素挂钩。它揭示了用户的总体体验,包括确定什么会拖慢客户预期的响应时间,通过设计满足带宽要求的内容交付来提高客户粘性,选择最佳设备,最终帮助企业发展业务。

问题

当然,这是对业务服务的性能工程价值的过度简化。为了理解在完成我刚刚所描述事情背后的挑战,让我们把它放到一个真实的稍微有点复杂的场景中。

现实世界的应用程序可能托管在云端。应用程序可以利用非常大(或概念上是无穷大)的计算资源。在硬件和软件方面的需求将通过云来满足。从事开发工作的开发人员将使用云交付功能来实现更快的编码和部署。云托管不是免费的,但成本开销与应用程序的资源需求成正比。

除了 搜索即服务 Search as a Service (SaaS)、 平台即服务 Platform as a Service (PaaS)、 基础设施即服务 Infrastructure as a Service (IaaS)以及 负载平衡即服务 Load Balancing as a Service (LBaaS)之外,当云端管理托管程序的流量时,开发人员可能还会使用这些快速增长的云服务中的一个或多个:

  • 安全即服务 Security as a Service (SECaaS),可满足软件和用户的安全需求
  • 数据即服务 Data as a Service (DaaS),为应用提供了用户需求的数据
  • 登录即服务 Logging as a Service (LaaS),DaaS 的近亲,提供了日志传递和使用的分析指标
  • 搜索即服务 Search as a Service (SaaS),用于应用程序的分析和大数据需求
  • 网络即服务 Network as a Service (NaaS),用于通过公共网络发送和接收数据

云服务也呈指数级增长,因为它们使得开发人员更容易编写复杂的应用程序。除了软件复杂性之外,所有这些分布式组件的相互作用变得越来越多。用户群变得更加多元化。该软件的需求列表变得更长。对其他服务的依赖性变大。由于这些因素,这个生态系统的缺陷会引发性能问题的多米诺效应。

例如,假设你有一个精心编写的应用程序,它遵循安全编码实践,旨在满足不同的负载要求,并经过彻底测试。另外假设你已经将基础架构和分析工作结合起来,以支持基本的性能要求。在系统的实现、设计和架构中建立性能标准需要做些什么?软件如何跟上不断变化的市场需求和新兴技术?如何测量关键参数以调整系统以获得最佳性能?如何使系统具有弹性和自我恢复能力?你如何更快地识别任何潜在的性能问题,并尽早解决?

进入容器

软件容器微服务设计或面向服务的架构(SoA)的优点为基础,提高了性能,因为包含更小的、自足的代码块的系统更容易编码,对其它系统组件有更清晰、定义良好的依赖。测试更容易,包括围绕资源利用和内存过度消耗的问题比在宏架构中更容易确定。

当扩容系统以增加负载能力时,容器应用程序的复制快速而简单。安全漏洞能更好地隔离。补丁可以独立版本化并快速部署。性能监控更有针对性,测量更可靠。你还可以重写和“改版”资源密集型代码,以满足不断变化的性能要求。

容器启动快速,停止也快速。它比虚拟机(VM)有更高效资源利用和更好的进程隔离。容器没有空闲内存和 CPU 闲置。它们允许多个应用程序共享机器,而不会丢失数据或性能。容器使应用程序可移植,因此开发人员可以构建并将应用程序发送到任何支持容器技术的 Linux 服务器上,而不必担心性能损失。容器生存在其内,并遵守其集群管理器(如 Cloud Foundry 的 Diego、Kubernetes、Apache Mesos 和 Docker Swarm)所规定的配额(比如包括存储、计算和对象计数配额)。

容器在性能方面表现出色,而即将到来的 “serverless” 计算(也称为 功能即服务 Function as a Service (FaaS))的浪潮将扩大容器的优势。在 FaaS 时代,这些临时性或短期的容器将带来超越应用程序性能的优势,直接转化为在云中托管的间接成本的节省。如果容器的工作更快,那么它的寿命就会更短,而且计算量负载纯粹是按需的。


作者简介:

Garima 是 Red Hat 的工程经理,专注于 OpenShift 容器平台。在加入 Red Hat 之前,Garima 帮助 Akamai Technologies&MathWorks Inc. 开创了创新。


via: https://opensource.com/article/17/2/performance-container-world

作者:Garima 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

在本文中,我们将解释 Linux 系统中最关键的管理任务之一——关于系统 / CPU 的 负载 load 平均负载 Load average 的性能监控。

首先来看所有的类 UNIX 系统中两个重要的表述:

  • 系统负载 / CPU 负载 – 衡量 Linux 系统的 CPU 过载或利用率低的指标,即处于运算状态或等待状态的 CPU 核心数。
  • 平均负载 – 通过固定的时间周期如 1、5、15 分钟计算出的平均的系统负载。

Linux 中,平均负载一般指在内核运行队列中被标记为运行或不可打断状态的进程的平均数。

注意:

  • 几乎没有 Linux 或类 Unix 系统不为用户展示平均负载的值。
  • 完全空闲的 Linux 系统平均负载为 0,不包括空闲进程。
  • 绝大多数类 Unix 系统只统计运行和等待状态的进程。但是在 Linux 中,平均负载也包括处于不可打断的睡眠状态的进程——它们是在等待其它系统资源如磁盘 I/O 等的进程。

如何监测 Linux 系统平均负载

有诸多方式监测系统平均负载,如 uptime,它会展示系统运行时间、用户数量及平均负载:

$ uptime
07:13:53 up 8 days, 19 min,  1 user,  load average: 1.98, 2.15, 2.21

平均负载的数字从左到右的含义依次为:

  • 最近 1 分钟的平均负载为 1.98
  • 最近 5 分钟的平均负载为 2.15
  • 最近 15 分钟的平均负载为 2.21

高平均负载意味着系统是过载的:许多进程在等待 CPU 时间。

下一节将介绍平均负载和 CPU 核数的关系。此外,常用的工具 topglances 可以实时显示 Linux 系统的运行状态:

Top命令

$ top

显示运行中的Linux进程:

top - 12:51:42 up  2:11,  1 user,  load average: 1.22, 1.12, 1.26
Tasks: 243 total,   1 running, 242 sleeping,   0 stopped,   0 zombie
%Cpu(s): 17.4 us,  2.9 sy,  0.3 ni, 74.8 id,  4.6 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  8069036 total,   388060 free,  4381184 used,  3299792 buff/cache
KiB Swap:  3906556 total,  3901876 free,     4680 used.  2807464 avail Mem 
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                        
6265 tecmint   20   0 1244348 170680  83616 S  13.3  2.1   6:47.72 Headset                                                                                                                                        
2301 tecmint    9 -11  640332  13344   9932 S   6.7  0.2   2:18.96 pulseaudio                                                                                                                                     
2459 tecmint   20   0 1707692 315628  62992 S   6.7  3.9   6:55.45 cinnamon                                                                                                                                       
2957 tecmint   20   0 2644644 1.035g 137968 S   6.7 13.5  50:11.13 firefox                                                                                                                                        
3208 tecmint   20   0  507060  52136  33152 S   6.7  0.6   0:04.34 gnome-terminal-                                                                                                                                
3272 tecmint   20   0 1521380 391324 178348 S   6.7  4.8   6:21.01 chrome                                                                                                                                         
6220 tecmint   20   0 1595392 106964  76836 S   6.7  1.3   3:31.94 Headset                                                                                                                                        
1 root      20   0  120056   6204   3964 S   0.0  0.1   0:01.83 systemd                                                                                                                                        
2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd                                                                                                                                       
3 root      20   0       0      0      0 S   0.0  0.0   0:00.10 ksoftirqd/0                                                                                                                                    
5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H   
....

Glances 工具

$ glances

Glances – Linux系统监测工具:

TecMint (LinuxMint 18 64bit / Linux 4.4.0-21-generic)                                                                                                                                               Uptime: 2:16:06
CPU      16.4%  nice:     0.1%                                        LOAD    4-core                                        MEM     60.5%  active:    4.90G                                        SWAP      0.1%
user:    10.2%  irq:      0.0%                                        1 min:    1.20                                        total:  7.70G  inactive:  2.07G                                        total:   3.73G
system:   3.4%  iowait:   2.7%                                        5 min:    1.16                                        used:   4.66G  buffers:    242M                                        used:    4.57M
idle:    83.6%  steal:    0.0%                                        15 min:   1.24                                        free:   3.04G  cached:    2.58G                                        free:    3.72G
NETWORK     Rx/s   Tx/s   TASKS 253 (883 thr), 1 run, 252 slp, 0 oth sorted automatically by cpu_percent, flat view
enp1s0     525Kb   31Kb
lo           2Kb    2Kb     CPU%  MEM%  VIRT   RES   PID USER        NI S    TIME+ IOR/s IOW/s Command 
wlp2s0        0b     0b     14.6  13.3 2.53G 1.03G  2957 tecmint      0 S 51:49.10     0   40K /usr/lib/firefox/firefox 
7.4   2.2 1.16G  176M  6265 tecmint      0 S  7:08.18     0     0 /usr/lib/Headset/Headset --type=renderer --no-sandbox --primordial-pipe-token=879B36514C6BEDB183D3E4142774D1DF --lan
DISK I/O     R/s    W/s      4.9   3.9 1.63G  310M  2459 tecmint      0 R  7:12.18     0     0 cinnamon --replace
ram0           0      0      4.2   0.2  625M 13.0M  2301 tecmint    -11 S  2:29.72     0     0 /usr/bin/pulseaudio --start --log-target=syslog
ram1           0      0      4.2   1.3 1.52G  105M  6220 tecmint      0 S  3:42.64     0     0 /usr/lib/Headset/Headset 
ram10          0      0      2.9   0.8  409M 66.7M  6240 tecmint      0 S  2:40.44     0     0 /usr/lib/Headset/Headset --type=gpu-process --no-sandbox --supports-dual-gpus=false --gpu-driver-bug-workarounds=7,2
ram11          0      0      2.9   1.8  531M  142M  1690 root         0 S  6:03.79     0     0 /usr/lib/xorg/Xorg :0 -audit 0 -auth /var/lib/mdm/:0.Xauth -nolisten tcp vt8
ram12          0      0      2.6   0.3 79.3M 23.8M  9651 tecmint      0 R  0:00.71     0     0 /usr/bin/python3 /usr/bin/glances
ram13          0      0      1.6   4.8 1.45G  382M  3272 tecmint      0 S  6:25.30     0    4K /opt/google/chrome/chrome 
...

这些工具中的平均负载是从 /proc/loadavg 文件中读取的,也可以直接使用 cat 命令查看:

$ cat /proc/loadavg
2.48 1.69 1.42 5/889 10570

想要图形样式监测平均负载,请戳:ttyload – 终端中颜色编码图形显示 Linux 平均负载

在桌面计算机中,可以使用图形用户接口工具查看系统平均负载。

理解系统平均负载和 CPU 核心数的关系

考虑了 CPU 核心数的影响,才能解释系统负载。

多处理器 Vs 多核处理器

  • 多处理器 – 一个计算机系统中集成两个或多个物理 CPU
  • 多核处理器 – 单个物理 CPU 有两个或多个单独的核并行工作(也叫处理单元)。双核意味着有两个处理单元,4 核有 4 个处理单元,以此类推。

此外,Intel 引入了超线程技术用来提高并行计算能力。

通过超线程技术,在操作系统中,单个物理 CPU 表现的和两个逻辑 CPU 一样。(实际在硬件上只有一个 CPU)。

注意,单个 CPU 核同一时间只能执行一个任务,于是产生了多 CPU/处理器、多核 CPU,以及多线程技术。

多 CPU 时,多个程序可以同时执行。如今的 Intel CPU 使用了多核心和超线程技术。

可以使用 nproc 或 lscpu 命令查看系统中的处理器单元数量。

$ nproc
4
# 或者
lscpu

也可以使用 grep 命令

$ grep 'model name' /proc/cpuinfo | wc -l
4

为了进一步理解系统负载,需要做一些假设。假设系统负载如下:

23:16:49 up  10:49,  5 user,  load average: 1.00, 0.40, 3.35

在单核系统中意味着:

  • CPU 被充分利用(100%);最近的 1 分钟有 1 个进程在运行。
  • CPU 有 60% 处于空闲状态;在最近的 5 分钟没有进程等待 CPU 时间。
  • CPU 平均过载了 235%;最近的 15 分钟平均有 2.35 个进程在等待 CPU 时间。

在双核系统中意味着:

  • 有一个 CPU 处于完全空闲状态,另一个 CPU 被使用;最近的 1 分钟没有进程等待 CPU 时间。
  • CPU 平均 160% 处于空闲状态;最近的 5 分钟没有进程等待 CPU 时间。
  • CPU 平均过载了 135%;最近的 15 分钟有 1.35 个进程等待 CPU 时间。

也许你还会喜欢:

  1. 20 个监控系统性能的命令行工具(一)
  2. 13 个 Linux 性能监控工具(二)
  3. Perf:一个 Linux 上的性能监控分析工具
  4. 使用 Nmon 监控 Linux 的系统性能

总而言之,如果你是系统管理员,你应该关注高的平均负载。平均负载高于 CPU 核心数意味着需要增加 CPU,反之则意味着 CPU 未被充分利用。


作者简介:

Aaron Kili 是 Linux 和自由软件的热心者,热衷于分享知识,现在是 TecMint 网站的内容创作者,不久之后将成为 Linux 系统管理员,web 开发者。


via: https://www.tecmint.com/understand-linux-load-averages-and-monitor-performance/

作者:Aaron Kili 译者:kylecao 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出