I suspect it comes from the Docker gateway, which is added to the execution path when we connect through port forwarding.
The throughput in this scenario is 2200 tps!!! That is a significant overhead. In this case, the container exposed port 3306 to the host, and we used that as an access point in sysbench. In the next experiment, I started Percona Server in a Docker container and connect to it from the host: docker run-eMYSQL_ALLOW_EMPTY_PASSWORD=1-name ps13-p3306:3306-v/data/flash/d1/:/var/lib/mysql-v/data/flash/my.cnf:/etc/my.cnf-net=host percona/percona-server:5.6.28 On the bare metal system, the throughput is 7100 transactions per second (tps). For reference, the command I used is the following: /opt/sysbench/sysbench-test=/opt/tests/db/a-oltp_tables_count=8-oltp_table_size=10000000-num-threads=16-mysql-host=172.18.0.2-mysql-user=root-oltp-read-only=on-max-time=1800-max-requests=0-report-interval=10run The Docker version is the latest on the day of publishing, which is 1.9.1.įirst, I measured the throughput on a bare server, without containers – this will be the baseline. My server is 24 cores (including hyper-threads), with Intel(R) Xeon(R) CPU E5-2643 v2 3.50GHz CPUs, RAM: 256GB, OS: Ubuntu 14.04. In this post, I will show the numbers for CPU and network intensive workloads, and later I will take a look at IO.įor the CPU-bound load, I will use a sysbench OLTP read-only workload with data fitting into memory (so there is no IO performed, and the execution path only goes through the network and CPU). Since Docker promises to use a lightweight container, in theory there should be very light overhead. Now that we have our Percona Server Docker images, I wanted to measure the performance overhead when we run the database in the container.
0 kommentar(er)
