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

我想全面了解Docker容器的运行时性能成本。我找到了对网络轶事是~100µs慢的参考。

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

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

228641 次浏览
小开

Docker本身不是虚拟化——相反，它是内核对不同进程命名空间、设备命名空间等支持之上的抽象；一个命名空间本质上并不比另一个更昂贵或更低效，所以真正让Docker产生性能影响的是那些命名空间实际上是在的问题。

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

  • 分层文件系统是昂贵的——确切地说，成本因每个文件系统而异（并且Docker支持多个后端），并且随着您的使用模式（合并多个大目录，或者合并一组非常深的文件系统将特别昂贵），但它们不是免费的。另一方面，Docker的大量功能——能够以写时复制的方式从其他来宾构建来宾，并获得相同的隐含存储优势——取决于支付此成本。
  • DNAT在规模上变得昂贵--但它使您能够独立于主机配置来宾的网络，并且有一个方便的接口，只在它们之间转发您想要的端口。您可以用连接到物理接口的网桥替换它，但同样失去了好处。
  • 能够以最方便的方式运行每个软件堆栈并安装其依赖项-独立于主机的发行版，libc和其他库版本-是一个很大的好处，但是需要多次加载共享库（当它们的版本不同时）具有您预期的成本。

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

小开
最佳答案

Felter等人的一篇优秀的2014IBM研究论文“虚拟机和Linux容器的更新性能比较”提供了裸机、KVM和Docker容器之间的比较。一般结果是：Docker几乎与原生性能相同，并且在每个类别中都比KVM更快。

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

Docker NAT开销

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

Docker Redis延迟开销

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

查看磁盘I/O：

Docker vs. KVM vs. Native I/O Performance

现在看看CPU开销：

Docker CPU开销

现在一些记忆的例子（阅读论文了解细节，记忆可能会更加棘手）：

Docker内存比较

小开

这里有一些更多的基准Docker based memcached server与host native memcached server使用Twemperf基准工具https://github.com/twitter/twemperf 5000连接和20k连接率

基于docker的memcache的连接时间开销似乎与上面的白皮书一致，大约是原生速度的两倍。

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

这里是使用memtier基准工具的bencmark

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
小开

运行时库比较

我将讨论关于容器的运行时性能成本和运行时库的问题。

速度：Musl vs. glibc

在AplineLinux容器中，使用运行时库由Musl提供来代替glibc，并且根据下面的链接，两者之间可能存在性能差异：

https://www.etalabs.net/compare_libcs.html

我已经阅读了研究这个主题的各种观点，这些观点既微小又显着更现代，Musl也赋予了对glibc更大程度的安全性。然而，还没有找到任何数据来支持这些观点。

兼容性

即使Musl更快更安全，它也会出现兼容性问题，因为Musl与glibc有本质上的不同。我发现如果我使用apk创建一个docker映像来拉取我的包，当然没有能力问题。

结论

如果性能很重要，用Musl裁剪（2）个容器，用AlpineLinux另一个容器，用glibc的发行版对它们进行基准测试。当然，在评论中发布你的结果！！！！


提交答案