为何同一群晖设备上Docker版MariaDB比原生包慢很多？

问题背景 #

• 设备：Synology DS1621xs+，配备NVMe SSD缓存、24GB内存，系统为DSM 7.1，文件系统btrfs，Docker版本20.10.3
• 现象：同一设备上，原生Synology MariaDB10包的数据库查询速度比Docker部署的同版本MariaDB快2.5倍以上，部分查询差距达20倍

核心原因分析 #

1. 存储层额外开销 #

• Docker使用btrfs作为存储驱动，虽然与主机文件系统一致，但容器采用分层镜像结构，读写操作会产生额外的层叠加、复制写（Copy-on-Write）开销，在数据库随机IO的场景下，这种损耗会被放大。
• 原生MariaDB直接使用主机的btrfs文件系统，IO路径无容器封装，效率更高。此外，需确认Docker根目录所在的/volume2是否启用了NVMe缓存——原生包的数据目录大概率在缓存加速的卷上，若Docker卷未配置缓存，性能差距会进一步拉大。

2. 资源管控与优先级差异 #

• 从Docker信息的警告来看，当前环境缺失CPU CFS配额/周期、blkio权重等Cgroup支持，容器无法充分利用系统资源；而群晖官方原生包的MariaDB进程可能被赋予更高的CPU、IO调度优先级，在资源竞争时能优先获取硬件资源。

3. MariaDB配置差异（关键因素） #

• 从容器日志可见，Docker版MariaDB的InnoDB缓冲池仅为128MB（日志中Initializing buffer pool, total size = 134217728对应128MB）。而群晖原生包会根据主机24GB内存自动配置大得多的缓冲池（通常为几GB），这会大幅提升数据缓存命中率，减少磁盘IO次数，直接带来查询速度的飞跃。
• 原生包针对群晖硬件做了专属优化配置（如IO调度、线程数、日志策略），而Docker镜像采用通用默认配置，未适配群晖环境。

4. 网络通信开销 #

• 若Docker容器使用默认bridge网络，访问时需经过NAT转发，产生额外网络开销；原生MariaDB可通过本地socket通信，无网络转发损耗。即使是本地访问容器，复杂查询场景下这种开销仍会显现。

优化建议 #

• 调大InnoDB缓冲池：修改Docker版MariaDB配置，设置innodb_buffer_pool_size=8G（建议占主机可用内存的50%-70%，根据实际情况调整）。
• 使用host网络：启动容器时添加--network=host参数，避免bridge网络的NAT开销，直接复用主机网络栈。
• 优化存储挂载：将Docker数据卷挂载到启用NVMe缓存的卷上，使用--volume挂载主机目录而非匿名卷，减少存储层额外开销。
• 同步优化配置：参考群晖原生MariaDB的配置参数，调整Docker版的线程数、IO相关参数，适配硬件环境。

内容的提问来源于stack exchange，提问作者David P.