EmergencyEMERGENCY? Get 24/7 Help Now!

Measuring Docker IO overhead

 | February 11, 2016 |  Posted In: Docker, MySQL, Percona Server for MySQL

PREVIOUS POST
NEXT POST

Docker IO overheadThis will be another post on using Percona Server via a Docker image. I want to follow up on my previous post regarding CPU/Network overhead in Docker “Measuring Percona Server Docker CPU/network overhead” by measuring  if there is any docker IO overhead on operations.

After running several tests, it appears (spoiler alert) that there is no Docker IO overhead. I still think it is useful to understand the different ways Docker can be used with data volumes, however. Docker’s philosophy is to provide ephemeral containers, but ephemeral does not work well for data – we do not want our data to disappear.

So, the first pattern is to create data inside a docker container. This is the default mode:

(I am using --net=host to avoid network overhead; check the previous post for more information.)

The second pattern is to use an external data volume, there we need to substitute the data volume with -v /data/flash/d1/:/var/lib/mysql. The full command is:

Finally, there is third pattern: using data volume containers. For this example, I created a dummy container:

After stopping the ps13-data-volume container, we can start a real one using the data volume from ps13-data-volume  as:

I compared all these modes with Percona Server running on a bare metal box, and direct mounted in sysbench, for both read-intensive and write-intensive IO workloads. For the reference, sysbench command is:

I’m not going to show the final numbers or charts, as the results are identical for all docker modes and for the bare metal case. So I can confidently say there is NO IO overhead for any docker data volume pattern described above.

As next experiment, I want to measure the Docker container overhead in a multi-host network environment.

PREVIOUS POST
NEXT POST
Vadim Tkachenko

Vadim Tkachenko co-founded Percona in 2006 and serves as its Chief Technology Officer. Vadim leads Percona Labs, which focuses on technology research and performance evaluations of Percona’s and third-party products. Percona Labs designs no-gimmick tests of hardware, filesystems, storage engines, and databases that surpass the standard performance and functionality scenario benchmarks. Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. Oracle Corporation and its predecessors have incorporated Vadim’s source code patches into the mainstream MySQL and InnoDB products. He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.

2 Comments

  • I think there’s an edge case here that can lead to some degradation when not using an external data volume.

    https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/#container-reads-and-writes-with-overlay

    “OverlayFS works at the file level not the block level. This means that all OverlayFS copy-up operations copy entire files, even if the file is very large and only a small part of it is being modified. This can have a noticeable impact on container write performance.”

    It might be a little contrived as an example, but if anyone ever thought to commit test data to their image (rather than create it on startup), you could see a one time hit as the files are copied up into the running containers.

    It looks like the overhead would be smaller with Overlay as opposed to AUFS, but I thought it was worth a mention.

  • I’m pretty sure this VOLUME instruction makes it always be made a bind mounted volume regardless of options to docker run: https://github.com/percona/percona-docker/blob/master/percona-server/Dockerfile#L17

Leave a Reply