Docker容器化的MySQL性能分析

说到部署，Docker将便携性和易用性拉高到一个新水准。MySQL相关的Dockerfile和脚本已经发布很长时间，在开发社区的使用率也稳步增长。这一点也在意料之中。

在影响到MySQL性能的每个环节上，用户的典型担忧在于：容器化以后，在这些环节上是否存在显著的性能开销。为此，我们进行了充分的性能测试，下面我会对测试结果的某些细节进行探讨。

我们的关注点主要在MySQL实例的IO和网络性能，尤其是对比采用了不同存储选项的实例，以及docker bridge网络模式带来了多少性能开销。测试的运行环境是：Oracle Server x5-2，处理器为2x Xeon E5-2660 v3（40硬件线程），256G内存，操作系统Ubuntu 16.04，Docker版本v1.11.2。

1. 默认是通过使用数据卷。使用Docker内部volumes管理功能，将数据写入宿主机的某个目录。

2．指定宿主机上的一个目录，将其挂载到容器内的特定位置。

3．创建一个数据卷容器，然后将数据卷共享给其它容器。

Docker 镜像是由一组layer构成，每一个layer代表文件系统的差异。Docker的存储驱动负责叠加这些layer，进而构成一个镜像。然而，跳过docker存储驱动的数据卷和宿主机目录，在性能上接近原生的存储。AUFS是使用最广泛的docker驱动程序，因此我们使用它进行测试。

为了测试网络开销，我们分别对Docker host和bridge网络进行了测试，方法是创建容器时分别指定–net=host 或–net=bridged。创建容器时，默认采用bridge模式。Host模式只是在宿主机的网络栈上增加了容器，因此应该能够避免bridge模式带来的性能开销。

测试时，我们使用了一个自定义的配置文件。为了增加I/O负载，首先我们特意将缓冲池大小设置为数据库大小的10%左右。数据库大小是2358MB，所以缓冲池大小为256MB。然后，我们将缓存池大小逐渐增加到16384MB，观察Docker不受I/O限制时，会出现什么情况。

Docker运行MySQL时，自定义配置是很直接的。最简单的方式是创建容器时将 /etc/my.cnf 挂载到容器中（-v /path/to/host/mycnf:/etc/mycnf）。你也可以修改容器，并将修改commit到镜像中，但是这种方法不太好，因为每次升级MySQL时，你都要设置一次。

我们已经使用 sysbench 进行了测试。我们运行以下命令，以便建立我们的测试数据库。

测试之前，先运行Warm-up测试，测试程序运行320s，见下方。然后运行完整的测试。每个测试运行三次，在下表的结果中反映了这三次运行的平均值。

在bridge模式下测试时，我们会在根据需要改变—mysql-host的地址。

我们发现，I/O高负载情况下，不同的方式测试结果差异性更小。Docker运行MySQL并没有显著的I/O或网络瓶颈。从这个角度看，Docker平台上的MySQL与直接运行在宿主机上并没有显著差别。值得注意的是：Docker上运行时，采用不同的存储选项和不采用存储选项并没有显著差别。

之后，我们将缓存池大小调整到16384MB，观察I/O负载低时，会发生什么情况。然后我们重新运行了一次测试用例。

结果表明，与直接运行在宿主机上的MySQL相比，运行在Docker上有一定的性能开销。网络上也存在微小的开销。仍然需要注意的是，docker不同的存储选项之间，性能并没有实际的差别。

一个关键因素是I/O负载，I/O负载过高会抹平MySQL在Docker和宿主机上的差异。当不受I/O负载影响时，Docker显示出小幅度的瓶颈，尤其是运行在bridge网络模式下时。

综合来说，docker不同的存储选项不会对MySQL性能产生较大影响，因此可以随意选择存储。非常重要的一点是，将MySQL运行在容器中时，要通过配置，对其进行性能调优。

容器化MySQL已经在测试和开发环境中大量使用，我们的测试结果也显示在生产环境中选择容器化MySQL并不需要性能方面的考虑。