|
|
前言
自从使用docker以来，就经常听说MySQL数据库最好别运行在容器中，性能会损失很多。一些之前没使用过容器的同事，对数据库运行在容器中也是忌讳莫深，甚至只要数据库跑在容器中出现性能问题时，首先就把问题推到容器上。
那么到底会损失多少，性能损失会很多吗？
为此我装了两个MySQL，版本都是8.0.34。一个用官网二进制包安装，另一个用docker hub的MySQL镜像安装。两个MySQL都运行在同一台机器，但不同时运行，先后运行测试。测试工具用的sysbench，运行在另一台机器。
提前声明：测试流程比较简单，只是用sysbench测了混合读写场景，测试次数也较少，不具有权威性。感兴趣的话，可以自行完善测试流程。
如果对后文没什么兴趣，这里也可以直接说结论：单表百万级以下时，非容器和容器的性能差异并不多。单表千万级时，容器MySQL大概会损耗10% ~ 20%的性能。
应用版本备注Debian12.0操作系统。4C16Gdocker20.10.17容器运行时MySQL（非docker）8.0.34基于官方的二进制安装包MySQL（docker）8.0.34使用docker hub的镜像sysbench1.0.20压测工具MySQL配置
MySQL安装后创建测试用的sysbench用户和sysbench数据库，调整innodb_buffer_pool_size为2GB。
docker容器的网络配置为bridge，挂载数据目录。
sysbench命令
- sysbench --db-driver=mysql --mysql-host=192.168.3.21 --mysql-port=3306 --mysql-user=sysbench --mysql-password=123456 --mysql-db=sysbench --table_size=10000000 --tables=20 --threads=4 oltp_read_write prepare
- sysbench --db-driver=mysql --mysql-host=192.168.3.21 --mysql-port=3306 --mysql-user=sysbench --mysql-password=123456 --mysql-db=sysbench --time=300 --threads=8 --report-interval=10 oltp_read_write run
- sysbench --db-driver=mysql --mysql-host=192.168.3.21 --mysql-port=3306 --mysql-user=sysbench --mysql-password=123456 --mysql-db=sysbench --table_size=10000000 --tables=20 --threads=4 oltp_read_write cleanup
单表1000w数据，20张表，测试4次。
MySQL运行环境测试序列总SQL执行数每秒SQL数每秒事务数延迟时间（平均）延迟时间（95%）非容器1379809312658.84632.7812.6420.00非容器2391457813047.91652.2812.2617.01非容器3405986713531.79676.4611.8215.55非容器4377239012574.00628.5812.7219.65容器1323067810768.41538.2814.8626.20容器2353857311794.68589.6213.5719.29容器3356794311892.56594.5013.4517.63容器4361620412053.53602.5813.2717.32平均统计：
MySQL运行环境总SQL执行数每秒SQL数每秒事务数延迟时间（平均）延迟时间（95%）非容器3,886,23212,953.14647.5312.3618.05容器3,488,35011,627.3581.2513.7920.11环比-10.24%-10.24%-10.24%+11.57%+11.41%在测千万级数据量之前，测过几轮几十万级的数据量，非容器和容器版的MySQL并没有多大区别。当数据量逐渐增多时，差异就愈加明显。目前测单表1000w已经出现10%左右的性能损耗，如果单表数据继续增大，性能损耗应该也会更多。
来源:https://www.cnblogs.com/XY-Heruo/p/17856386.html
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！ |
|
