ChatGPT解决这个技术问题 Extra ChatGPT

What is the runtime performance cost of a Docker container?

I'd like to comprehensively understand the run-time performance cost of a Docker container. I've found references to networking anecdotally being ~100µs slower.

I've also found references to the run-time cost being "negligible" and "close to zero" but I'd like to know more precisely what those costs are. Ideally I'd like to know what Docker is abstracting with a performance cost and things that are abstracted without a performance cost. Networking, CPU, memory, etc.

Furthermore, if there are abstraction costs, are there ways to get around the abstraction cost. For example, perhaps I can mount a disk directly vs. virtually in Docker.

@GoloRoden that question is similar but not exactly the same. I'm looking for latency costs with reasons like "networking is being passed through an extra layer" whereas that question's accepted answer is more about measuring the costs of the container + app.
Okay, that's right. I retracted my close vote.
I'm glad you posted it though. That question didn't come up in my search. The measurement/metrics article is super useful: blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics
This is a good session titled "Linux Containers - NextGen Virtualization for Cloud" telling performance metrics by comparing docker, KVM VM and bare metal: youtube.com/watch?v=a4oOAVhNLjU

i
ib.

An excellent 2014 IBM research paper “An Updated Performance Comparison of Virtual Machines and Linux Containers” by Felter et al. provides a comparison between bare metal, KVM, and Docker containers. The general result is: Docker is nearly identical to native performance and faster than KVM in every category.

The exception to this is Docker’s NAT — if you use port mapping (e.g., docker run -p 8080:8080), then you can expect a minor hit in latency, as shown below. However, you can now use the host network stack (e.g., docker run --net=host) when launching a Docker container, which will perform identically to the Native column (as shown in the Redis latency results lower down).

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

They also ran latency tests on a few specific services, such as Redis. You can see that above 20 client threads, highest latency overhead goes Docker NAT, then KVM, then a rough tie between Docker host/native.

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

Just because it’s a really useful paper, here are some other figures. Please download it for full access.

Taking a look at Disk I/O:

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

Now looking at CPU overhead:

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

Now some examples of memory (read the paper for details, memory can be extra tricky):

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


As for the linpack numbers given in the paper... frankly, I find them hard to believe (not that I disbelieve that they're what linpack emitted, but that I disbelieve that the test was genuinely measuring nothing but floating-point performance as performed). The major overhead from KVM is in the userspace hardware emulation components (which only apply to non-CPU hardware); there's significant overhead around memory paging... but raw floating-point? I'd want to look at what was actually going on there -- perhaps excessive context switches.
The cited IBM paper seems too focused on network IO. It never addresses context switches. We looked at LXC and had to quickly abandon it due to increased non-voluntary context switches resulting in degraded application processing.
I'm also curious about filesystem operations -- directory lookups, for instance, are a place where I'd expect to see overhead; block-level reads, writes and seeks (which the given charts focus heavily on) aren't.
I love charts with the same shade color. It's so easy to distinguish
More interested in docker versus native than docker vs any kind of vm.
C
Charles Duffy

Docker isn't virtualization, as such -- instead, it's an abstraction on top of the kernel's support for different process namespaces, device namespaces, etc.; one namespace isn't inherently more expensive or inefficient than another, so what actually makes Docker have a performance impact is a matter of what's actually in those namespaces.

Docker's choices in terms of how it configures namespaces for its containers have costs, but those costs are all directly associated with benefits -- you can give them up, but in doing so you also give up the associated benefit:

Layered filesystems are expensive -- exactly what the costs are vary with each one (and Docker supports multiple backends), and with your usage patterns (merging multiple large directories, or merging a very deep set of filesystems will be particularly expensive), but they're not free. On the other hand, a great deal of Docker's functionality -- being able to build guests off other guests in a copy-on-write manner, and getting the storage advantages implicit in same -- ride on paying this cost.

DNAT gets expensive at scale -- but gives you the benefit of being able to configure your guest's networking independently of your host's and have a convenient interface for forwarding only the ports you want between them. You can replace this with a bridge to a physical interface, but again, lose the benefit.

Being able to run each software stack with its dependencies installed in the most convenient manner -- independent of the host's distro, libc, and other library versions -- is a great benefit, but needing to load shared libraries more than once (when their versions differ) has the cost you'd expect.

And so forth. How much these costs actually impact you in your environment -- with your network access patterns, your memory constraints, etc -- is an item for which it's difficult to provide a generic answer.


This is a good answer but I'm looking for more specific numbers and benchmarks. I'm familiar with the cost of cgroups but Docker is more than that as you've pointed out. Thanks a lot for the answer.
Sure. My point is that any generalized benchmarks you find will be of very limited applicability to any specific application -- but that's not to say I disagree with folks trying to provide them, but merely that they should be taken with a heaping tablespoon of salt.
In that manner you could say that KVM "is not a virtualization it is simply an abstraction on top of x86 virtual technology calls".
@Vad, there's consensus agreement, going back decades (to IBM's early non-x86 hardware implementations!), that providing abstraction directly on the hardware layer is unambiguously virtualization. Consensus for terminology around kernel-level namespacing is considerably more fragmented -- we could each point to sources favoring our individual views -- but frankly, there are useful technical distinctions (around both security and performance characteristics) that moving to a single term would obscure, so I'm holding my position until and unless contrary industry consensus is reached.
@LukeHoersten, ...right, it's not the cgroups that have a significant cost, it's much more the contents of the network and filesystem namespaces. But how much those costs are depends almost entirely on how Docker is configured -- which specific backends you're using. Bridging is much, much cheaper than Docker's default NAT, for example; and the various filesystem backends' performance overhead also varies wildly (and in some cases, the amount of overhead depends on usage patterns; overlayfs variants can be much more expensive with big directories modified through multiple layers f/e).
p
p4guru

Here's some more benchmarks for Docker based memcached server versus host native memcached server using Twemperf benchmark tool https://github.com/twitter/twemperf with 5000 connections and 20k connection rate

Connect time overhead for docker based memcached seems to agree with above whitepaper at roughly twice native speed.

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

Here's 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

They compare two different builds of memcached, and also one of them in docker, other outside of docker, aren't they?
Are these results with host networking or bridge networking in docker?
With such big stddevs these measurements do not show any representable data avg 200.5 min 0.6 max 263.2 stddev 73.85