MySQL運(yùn)行在docker容器性能損失解析
前言
自從使用docker以來(lái),就經(jīng)常聽說(shuō)MySQL數(shù)據(jù)庫(kù)最好別運(yùn)行在容器中,性能會(huì)損失很多。一些之前沒(méi)使用過(guò)容器的同事,對(duì)數(shù)據(jù)庫(kù)運(yùn)行在容器中也是忌諱莫深,甚至只要數(shù)據(jù)庫(kù)跑在容器中出現(xiàn)性能問(wèn)題時(shí),首先就把問(wèn)題推到容器上。
那么到底會(huì)損失多少,性能損失會(huì)很多嗎?
為此我裝了兩個(gè)MySQL,版本都是8.0.34。一個(gè)用官網(wǎng)二進(jìn)制包安裝,另一個(gè)用docker hub的MySQL鏡像安裝。兩個(gè)MySQL都運(yùn)行在同一臺(tái)機(jī)器,但不同時(shí)運(yùn)行,先后運(yùn)行測(cè)試。測(cè)試工具用的sysbench,運(yùn)行在另一臺(tái)機(jī)器。
提前聲明:測(cè)試流程比較簡(jiǎn)單,只是用sysbench測(cè)了混合讀寫場(chǎng)景,測(cè)試次數(shù)也較少,不具有權(quán)威性。感興趣的話,可以自行完善測(cè)試流程。
如果對(duì)后文沒(méi)什么興趣,這里也可以直接說(shuō)結(jié)論:單表百萬(wàn)級(jí)以下時(shí),非容器和容器的性能差異并不多。單表千萬(wàn)級(jí)時(shí),容器MySQL大概會(huì)損耗10% ~ 20%的性能。
應(yīng)用 | 版本 | 備注 |
---|---|---|
Debian | 12.0 | 操作系統(tǒng)。4C16G |
docker | 20.10.17 | 容器運(yùn)行時(shí) |
MySQL(非docker) | 8.0.34 | 基于官方的二進(jìn)制安裝包 |
MySQL(docker) | 8.0.34 | 使用docker hub的鏡像 |
sysbench | 1.0.20 | 壓測(cè)工具 |
MySQL配置
MySQL安裝后創(chuàng)建測(cè)試用的sysbench用戶和sysbench數(shù)據(jù)庫(kù),調(diào)整innodb_buffer_pool_size為2GB。
docker容器的網(wǎng)絡(luò)配置為bridge,掛載數(shù)據(jù)目錄。
sysbench命令
- 準(zhǔn)備數(shù)據(jù)
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
- 執(zhí)行測(cè)試
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
- 清理測(cè)試數(shù)據(jù)
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
測(cè)試結(jié)果
單表1000w數(shù)據(jù),20張表,測(cè)試4次。
MySQL運(yùn)行環(huán)境 | 測(cè)試序列 | 總SQL執(zhí)行數(shù) | 每秒SQL數(shù) | 每秒事務(wù)數(shù) | 延遲時(shí)間(平均) | 延遲時(shí)間(95%) |
---|---|---|---|---|---|---|
非容器 | 1 | 3798093 | 12658.84 | 632.78 | 12.64 | 20.00 |
非容器 | 2 | 3914578 | 13047.91 | 652.28 | 12.26 | 17.01 |
非容器 | 3 | 4059867 | 13531.79 | 676.46 | 11.82 | 15.55 |
非容器 | 4 | 3772390 | 12574.00 | 628.58 | 12.72 | 19.65 |
容器 | 1 | 3230678 | 10768.41 | 538.28 | 14.86 | 26.20 |
容器 | 2 | 3538573 | 11794.68 | 589.62 | 13.57 | 19.29 |
容器 | 3 | 3567943 | 11892.56 | 594.50 | 13.45 | 17.63 |
容器 | 4 | 3616204 | 12053.53 | 602.58 | 13.27 | 17.32 |
平均統(tǒng)計(jì):
MySQL運(yùn)行環(huán)境 | 總SQL執(zhí)行數(shù) | 每秒SQL數(shù) | 每秒事務(wù)數(shù) | 延遲時(shí)間(平均) | 延遲時(shí)間(95%) |
---|---|---|---|---|---|
非容器 | 3,886,232 | 12,953.14 | 647.53 | 12.36 | 18.05 |
容器 | 3,488,350 | 11,627.3 | 581.25 | 13.79 | 20.11 |
環(huán)比 | -10.24% | -10.24% | -10.24% | +11.57% | +11.41% |
在測(cè)千萬(wàn)級(jí)數(shù)據(jù)量之前,測(cè)過(guò)幾輪幾十萬(wàn)級(jí)的數(shù)據(jù)量,非容器和容器版的MySQL并沒(méi)有多大區(qū)別。當(dāng)數(shù)據(jù)量逐漸增多時(shí),差異就愈加明顯。目前測(cè)單表1000w已經(jīng)出現(xiàn)10%左右的性能損耗,如果單表數(shù)據(jù)繼續(xù)增大,性能損耗應(yīng)該也會(huì)更多。
以上就是MySQL運(yùn)行在docker容器性能損失解析的詳細(xì)內(nèi)容,更多關(guān)于MySQL docker性能的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
mysql開啟遠(yuǎn)程連接(mysql開啟遠(yuǎn)程訪問(wèn))
開啟MYSQL遠(yuǎn)程連接權(quán)限的方法,大家參考使用吧2013-12-12MySQL參數(shù)lower_case_table_name的實(shí)現(xiàn)
lower_case_table_names是一個(gè)重要的系統(tǒng)變量,它影響著MySQL如何處理表名的大小寫,本文主要介紹了MySQL參數(shù)lower_case_table_name的實(shí)現(xiàn),感興趣的可以了解一下2024-08-08MySQL服務(wù)器進(jìn)程CPU占用100%的解決方法
早上幫朋友一臺(tái)服務(wù)器解決了 Mysql cpu 占用 100% 的問(wèn)題。稍整理了一下,將經(jīng)驗(yàn)記錄在這篇文章里。2010-12-12MySQL:reading initial communication packet問(wèn)題解決方法
網(wǎng)站訪問(wèn)出現(xiàn)如題錯(cuò)誤,經(jīng)過(guò)檢查my.cnf,發(fā)現(xiàn)innodb_buffer_pool_size = 2048M 設(shè)置過(guò)大,調(diào)整為innodb_buffer_pool_size = 1024M即可,網(wǎng)上也有該問(wèn)題的其他解決方法,但都不能解決我的問(wèn)題2012-07-07MySQL多版本并發(fā)控制MVCC深入學(xué)習(xí)
這篇文章主要介紹了MySQL多版本并發(fā)控制MVCC,小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2021-11-11