系统与数据库2017arxiv.org
Docker 如何影响能耗？
How does Docker affect energy consumption?
进阶 · 约 25 分钟读完前置知识：Linux 容器基础、虚拟化基础、能耗测量方法
导读
这篇论文研究了Docker容器相比直接在宿主机上运行对能耗的影响，通过实验测量不同工作负载下的能耗差异。评论指出论文发现容器化可能带来约10%的额外能耗，且部分原因是任务执行时间更长。
HN 关注点：容器化在资源整合与隔离之外的实际能耗代价，以及论文是否考虑了多组件架构的整体效率。
HN 评论精选
这几条评论里：质疑 1 补充 2 亲历 1
质疑论文忽略了容器通过整合工作负载减少机器/VM数量所带来的整体资源效率提升。
这篇文章是否忽略了更大、更实际的图景，即多组件架构中的整体资源效率/足迹？容器允许我们在单一OS运行时中压缩工作负载（同时保持隔离），而否则相同工作负载会跨多台机器或VM，每个都有开销和闲置资源。例如：你需要部署的不是单个Wordpress、Redis、Postgres实例，而是由许多这类组件组成的复杂应用。你可以选择(a)每个部署在不同机器[承担OS开销和未使用资源]；(b)不同VM[承担OS成本但能共享资源池]；(c)容器，共享OS并承担容器守护进程开销。我希望看到考虑这些点的文章。
raulk查看英文原文
Doesn't this article fail to consider the bigger, practical picture, i.e. overall resource efficiency/footprint in multi-component architectures? Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources). Example: consider you need to deploy not just a single instance of Wordpress, Redis, Postgres, etc., but a complex application consisting of many of those components. You can either choose to (a) deploy each in a different machine [incurring in the overhead of OS + unused resources]; (b) in different VMs [incurring in the cost of OS, but being able to share a resource pool]; or (c) in containers, sharing the OS and incurring in the overhead of the container daemon. I would love to see an article that takes these points into account.
亲历呼吁更全面的容器开销研究，特别是网络和存储，并分享自身观察到30%性能下降的经历。
说实话，我非常希望看到更多对容器开销的深度研究——不仅从内核角度，还有针对存储和网络开销的实际对比测量，涵盖不同文件系统选项（我知道aufs过时了，但我也用过overlay和btrfs），而且很可能最重要的是网络开销。我在Swarm中有些东西的每秒请求数比容器外运行下降了约30%（可以说是四五个移动部件，纯属轶事，但仍让我 pause），我真的很想理解如何削减这个。
rcarmo查看英文原文
Honestly, I'd very much like to see more deep studies into container overhead - not just from a kernel standpoint, but actual tit-for-tat measures for storage and networking overhead that spanned the different filesystem options (I know that aufs is old hat, but I've used overlay and btrfs too) and, probably most importantly, the networking overhead. I've had slowdowns in the order of 30% in terms of requests per second on some of my stuff inside Swarm as compared to running processes outside containers (arguably with four or five moving parts and entirely anecdotal, but still enough to give me pause), and I'd really like to understand how to shave this yak.
补充论文数据显示容器增加约10%能耗，但实际成本影响有限，因为计算资源通常未充分利用。
粗略看图表，TL;DR似乎是：是的，能耗增加约10%，有时只是因为任务耗时更长。另一点要注意：redis和postgres是I/O密集的，许多生产环境（尤其在AWS）选择不docker化I/O密集的东西。我希望论文能有类似陈述，这样我就不必冒险给出目测估计了，但这类陈述更难辩护，他们提供的数据也更微妙。话虽如此，实际运营中电力与成本大多脱钩，除非极端规模。这是因为可购买和计费的计算单元通常不会100%利用，云和裸机都是。换句话说，大多数人预付的“电力预算”超过实际使用。由于Docker的主要用途（尤其通过kube）是工作负载整合，很难知道这对世界有什么真实影响。
zxcmx查看英文原文
By eyeballing the graphs it looks like "tl:dr", yes by about 10%, and sometimes just because a job takes longer. Another thing to note is that redis and postgres are i/o heavy and many production environments (esp in aws) will choose not to dockerise i/o heavy stuff. I wish they had included a statement like that so I didn't have to stick my neck out and give an eyeball estimate, but I suppose this kind of statement is harder to defend and the data they provided was more nuanced. With that said, power is largely divorced from cost in actual operation except at extreme scale. This is because purchaseable and billable units of compute are usually not utilised to 100% capacity, both in cloud and bare-metal situations. Another way to say this is, most people essentially prepay more "power budget" than they actually use. Since a primary use of docker (esp via kube) is workload consolidation, it's hard to know what real impact this has on the world.
补充希望补充VM作为对比基线的能耗数据。
如果比较能包括在VM中运行Linux的测试就太好了。有人有这样的数据吗？（裸Linux vs Docker vs VM）
mbertschler查看英文原文
It would be awesome if the comparisons would include tests of Linux in a VM. Does anyone have such data? (bare Linux vs. Docker vs. VM)
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2017Hacker News 讨论帖174 分 · 86 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选