How does Docker affect energy consumption? Evaluating workloads in and out of Docker containers

Context: Virtual machines provide isolation of services at the cost of hypervisors and more resource usage. This spurred the growth of systems like Docker that enable single hosts to isolate several applications, similar to VMs, within a low-overhead abstraction called containers. Motivation: Although containers tout low overhead performance, do they still have low energy consumption? Methodology: This work statistically compares ($t$-test, Wilcoxon) the energy consumption of three application workloads in Docker and on bare-metal Linux. Results: In all cases, there was a statistically significant ($t$-test and Wilcoxon $p < 0.05$) increase in energy consumption when running tests in Docker, mostly due to the performance of I/O system calls.

💡 Research Summary

The paper presents an empirical study of the energy impact of Docker containers compared with bare‑metal Linux. Three widely used open‑source workloads—WordPress with MySQL, Redis, and PostgreSQL—were selected to represent different resource profiles (CPU‑I/O mixed, memory‑intensive, and disk‑intensive). The authors used two identical Dell PowerEdge R710 servers: one as the System‑Under‑Test (SUT) and another as a separate test‑runner that initiates workloads and records power data. Power consumption was measured with a Watts Up? Pro device that provides RMS‑averaged wattage once per second. Energy for each run was estimated by summing the per‑second power samples (rectangle rule). Each experiment consisted of 40 repetitions, with a two‑minute idle period before each run to ensure a stable baseline.

In the bare‑metal configuration, services were installed directly via apt‑get or compiled from source. In the Docker configuration, official Docker Hub images and Docker Compose were used, creating separate containers for Apache‑PHP and MySQL in the WordPress case, and single containers for Redis and PostgreSQL.

Statistical analysis (independent‑samples t‑test and non‑parametric Wilcoxon test) showed that Docker consistently consumed more energy than bare‑metal across all three workloads, with p < 0.05 for both tests. The magnitude of the increase varied: the disk‑heavy PostgreSQL benchmark exhibited roughly a 7 % rise in energy use, while the memory‑bound Redis workload showed about a 3 % increase.

The authors attribute the overhead primarily to Docker’s additional software layers: the Docker daemon, namespace isolation, cgroup resource control, and the UnionFS file‑system abstraction. These layers generate extra system calls, especially during I/O operations, and the copy‑on‑write mechanism introduces latency that translates into higher CPU idle time and greater power draw. Network virtualization also adds a modest overhead.

Limitations are acknowledged. The measurement captures total system power rather than component‑level consumption (e.g., CPU‑only RAPL), which may mask finer‑grained effects. The study used Docker 1.12.1 and Linux kernel 4.4; newer releases may contain performance optimizations not reflected here. Moreover, only three workloads were examined, so results may not generalize to large‑scale distributed services, GPU‑accelerated workloads, or real‑time streaming applications.

In conclusion, while Docker offers rapid deployment and lightweight isolation, it does not provide a free lunch in terms of energy efficiency. For I/O‑intensive applications, Docker incurs a measurable energy penalty compared with native execution. Practitioners should therefore evaluate both performance and power consumption when deciding whether to containerize workloads, especially in energy‑constrained or cost‑sensitive environments.