ChatGPT解决这个技术问题 Extra ChatGPT

Docker 容器的运行时性能成本是多少?

我想全面了解一个 Docker 容器的运行时性能成本。我找到了对 networking anecdotally being ~100µs slower 的引用。

我还发现对运行时成本的引用“可以忽略不计”和“接近于零”,但我想更准确地知道这些成本是什么。理想情况下,我想知道 Docker 以性能成本抽象了什么,以及在没有性能成本的情况下抽象的东西。网络、CPU、内存等

此外,如果有抽象成本,有没有办法绕过抽象成本。例如,也许我可以直接挂载磁盘而不是在 Docker 中虚拟挂载。

@GoloRoden 这个问题很相似,但并不完全相同。我正在寻找延迟成本,原因是“网络正在通过一个额外的层”,而这个问题的公认答案更多地是关于衡量容器 + 应用程序的成本。
好的,没错。我撤回了我的近距离投票。
我很高兴你发布了它。这个问题在我的搜索中没有出现。测量/指标文章非常有用:blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics
这是一个名为“Linux Containers - NextGen Virtualization for Cloud”的精彩会议,通过比较 docker、KVM VM 和裸机来讲述性能指标:youtube.com/watch?v=a4oOAVhNLjU

i
ib.

Felter 等人在 2014 年发表的一篇出色的 IBM 研究论文“An Updated Performance Comparison of Virtual Machines and Linux Containers”。提供了裸机、KVM 和 Docker 容器之间的比较。总体结果是:Docker 几乎与原生性能相同,并且在每个类别中都比 KVM 更快。

Docker 的 NAT 是个例外——如果您使用端口映射(例如,docker run -p 8080:8080),那么您可以预期延迟会受到轻微影响,如下所示。但是,您现在可以在启动 Docker 容器时使用主机网络堆栈(例如,docker run --net=host),这将与 Native 列相同(如下面的 Redis 延迟结果所示)。

https://i.stack.imgur.com/4yRh1m.png

他们还对一些特定服务(例如 Redis)进行了延迟测试。您可以看到超过 20 个客户端线程,延迟开销最高的是 Docker NAT,然后是 KVM,然后是 Docker 主机/本机之间的粗略联系。

https://i.stack.imgur.com/9RH9lm.png

仅仅因为它是一篇非常有用的论文,这里有一些其他的数字。请下载它以获得完全访问权限。

看一下磁盘 I/O:

https://i.stack.imgur.com/2Ftytm.png

现在查看 CPU 开销:

https://i.stack.imgur.com/wZZH6m.png

现在一些内存示例(阅读论文了解详细信息,内存可能特别棘手):

https://i.stack.imgur.com/aHPVkm.png


至于论文中给出的 linpack 数字......坦率地说,我发现它们很难相信(不是我不相信它们是 linpack 发出的,而是我不相信该测试真正测量的只是浮点性能执行)。 KVM 的主要开销在于用户空间硬件仿真组件(仅适用于非 CPU 硬件);内存分页有很大的开销......但是原始浮点?我想看看那里实际发生了什么——也许是过度的上下文切换。
引用的 IBM 论文似乎过于关注网络 IO。它从不解决上下文切换。我们研究了 LXC,但由于非自愿上下文切换增加导致应用程序处理性能下降,我们不得不迅速放弃它。
我也对文件系统操作很好奇——例如,目录查找是我希望看到开销的地方;块级读取、写入和查找(给定图表重点关注)不是。
我喜欢具有相同阴影颜色的图表。很容易区分
对 docker 与 native 比对 docker 与任何类型的 vm 更感兴趣。
C
Charles Duffy

Docker 本身并不是虚拟化——相反,它是内核对不同进程命名空间、设备命名空间等的支持之上的抽象;一个命名空间本质上并不比另一个命名空间更昂贵或效率低下,因此真正使 Docker 对性能产生影响的原因在于这些命名空间中的实际内容。

Docker 在如何为其容器配置命名空间方面的选择是有成本的,但这些成本都与收益直接相关——你可以放弃它们,但这样做你也放弃了相关的收益:

分层文件系统很昂贵——确切地说,每个系统的成本都不同(Docker 支持多个后端),以及您的使用模式(合并多个大目录,或合并一组非常深的文件系统将特别昂贵),但它们'不是免费的。另一方面,Docker 的大量功能——能够以写时复制的方式从其他来宾构建来宾,并获得其中隐含的存储优势——依赖于支付这笔费用。

DNAT 在规模上变得昂贵——但给您带来的好处是能够独立于您的主机配置您的访客网络,并有一个方便的接口,只在它们之间转发您想要的端口。您可以将其替换为物理接口的桥接,但同样失去了好处。

能够以最方便的方式运行每个安装了依赖项的软件堆栈——独立于主机的发行版、libc 和其他库版本——是一个很大的好处,但需要多次加载共享库(当它们的版本不同)具有您期望的成本。

等等。这些成本在您的环境中对您的实际影响有多大——包括您的网络访问模式、内存限制等——是一个很难提供通用答案的项目。


这是一个很好的答案,但我正在寻找更具体的数字和基准。我熟悉 cgroups 的成本,但正如您所指出的,Docker 不止于此。非常感谢您的回答。
当然。我的观点是,您发现的任何通用基准对任何特定应用程序的适用性都非常有限——但这并不是说我不同意试图提供它们的人们,而只是认为它们应该用一大汤匙盐来处理。
以这种方式,您可以说 KVM“不是虚拟化,它只是 x86 虚拟技术调用之上的抽象”。
@Vad,有共识协议,可以追溯到几十年前(IBM 早期的非 x86 硬件实现!),直接在硬件层上提供抽象是明确的虚拟化。围绕内核级命名空间的术语共识相当分散——我们每个人都可以指出有利于我们个人观点的来源——但坦率地说,有一些有用的技术区别(围绕安全性和性能特征)转移到一个术语会模糊,所以我将保持我的立场,直到并且除非达成相反的行业共识。
@LukeHoersten,...对,成本高昂的不是 cgroup,而是网络和文件系统命名空间的内容。但是这些成本的多少几乎完全取决于 Docker 的配置方式——您使用的是哪些特定的后端。例如,桥接比 Docker 的默认 NAT 便宜得多;并且各种文件系统后端的性能开销也有很大差异(在某些情况下,开销的数量取决于使用模式;overlayfs 变体可能会因为通过多层 f/e 修改的大目录而变得更加昂贵)。
p
p4guru

以下是使用具有 5000 个连接和 20k 连接速率的 Twemperf 基准工具 https://github.com/twitter/twemperfDocker based memcached serverhost native memcached server 的更多benchmarks

基于 docker 的 memcached 的连接时间开销似乎与上述白皮书一致,大约是本机速度的两倍。

Twemperf Docker Memcached

Connection rate: 9817.9 conn/s
Connection time [ms]: avg 341.1 min 73.7 max 396.2 stddev 52.11
Connect time [ms]: avg 55.0 min 1.1 max 103.1 stddev 28.14
Request rate: 83942.7 req/s (0.0 ms/req)
Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00
Response rate: 83942.7 rsp/s (0.0 ms/rsp)
Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00
Response time [ms]: avg 28.6 min 1.2 max 65.0 stddev 0.01
Response time [ms]: p25 24.0 p50 27.0 p75 29.0
Response time [ms]: p95 58.0 p99 62.0 p999 65.0

Twemperf Centmin Mod Memcached

Connection rate: 11419.3 conn/s
Connection time [ms]: avg 200.5 min 0.6 max 263.2 stddev 73.85
Connect time [ms]: avg 26.2 min 0.0 max 53.5 stddev 14.59
Request rate: 114192.6 req/s (0.0 ms/req)
Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00
Response rate: 114192.6 rsp/s (0.0 ms/rsp)
Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00
Response time [ms]: avg 17.4 min 0.0 max 28.8 stddev 0.01
Response time [ms]: p25 12.0 p50 20.0 p75 23.0
Response time [ms]: p95 28.0 p99 28.0 p999 29.0

这是bencmarks using memtier benchmark tool

memtier_benchmark docker Memcached

4         Threads
50        Connections per thread
10000     Requests per thread
Type        Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
------------------------------------------------------------------------
Sets       16821.99          ---          ---      1.12600      2271.79
Gets      168035.07    159636.00      8399.07      1.12000     23884.00
Totals    184857.06    159636.00      8399.07      1.12100     26155.79

memtier_benchmark Centmin Mod Memcached

4         Threads
50        Connections per thread
10000     Requests per thread
Type        Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
------------------------------------------------------------------------
Sets       28468.13          ---          ---      0.62300      3844.59
Gets      284368.51    266547.14     17821.36      0.62200     39964.31
Totals    312836.64    266547.14     17821.36      0.62200     43808.90

他们比较了两种不同的 memcached 版本,其中一个在 docker 中,另一个在 docker 之外,不是吗?
这些结果是 docker 中的主机网络还是桥接网络?
有了这么大的标准设备,这些测量结果不会显示任何可表示的数据 avg 200.5 min 0.6 max 263.2 stddev 73.85