MySQL運(yùn)行在docker容器性能損失解析
前言
自從使用docker以來，就經(jīng)常聽說MySQL數(shù)據(jù)庫最好別運(yùn)行在容器中，性能會損失很多。一些之前沒使用過容器的同事，對數(shù)據(jù)庫運(yùn)行在容器中也是忌諱莫深，甚至只要數(shù)據(jù)庫跑在容器中出現(xiàn)性能問題時，首先就把問題推到容器上。
那么到底會損失多少，性能損失會很多嗎？
為此我裝了兩個MySQL，版本都是8.0.34。一個用官網(wǎng)二進(jìn)制包安裝，另一個用docker hub的MySQL鏡像安裝。兩個MySQL都運(yùn)行在同一臺機(jī)器，但不同時運(yùn)行，先后運(yùn)行測試。測試工具用的sysbench，運(yùn)行在另一臺機(jī)器。
提前聲明：測試流程比較簡單，只是用sysbench測了混合讀寫場景，測試次數(shù)也較少，不具有權(quán)威性。感興趣的話，可以自行完善測試流程。
如果對后文沒什么興趣，這里也可以直接說結(jié)論：單表百萬級以下時，非容器和容器的性能差異并不多。單表千萬級時，容器MySQL大概會損耗10% ~ 20%的性能。
| 應(yīng)用 | 版本 | 備注 |
|---|---|---|
| Debian | 12.0 | 操作系統(tǒng)。4C16G |
| docker | 20.10.17 | 容器運(yùn)行時 |
| MySQL（非docker） | 8.0.34 | 基于官方的二進(jìn)制安裝包 |
| MySQL（docker） | 8.0.34 | 使用docker hub的鏡像 |
| sysbench | 1.0.20 | 壓測工具 |
MySQL配置
MySQL安裝后創(chuàng)建測試用的sysbench用戶和sysbench數(shù)據(jù)庫，調(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í)行測試
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
- 清理測試數(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
測試結(jié)果
單表1000w數(shù)據(jù)，20張表，測試4次。
| MySQL運(yùn)行環(huán)境 | 測試序列 | 總SQL執(zhí)行數(shù) | 每秒SQL數(shù) | 每秒事務(wù)數(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)計：
| MySQL運(yùn)行環(huán)境 | 總SQL執(zhí)行數(shù) | 每秒SQL數(shù) | 每秒事務(wù)數(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% |
在測千萬級數(shù)據(jù)量之前，測過幾輪幾十萬級的數(shù)據(jù)量，非容器和容器版的MySQL并沒有多大區(qū)別。當(dāng)數(shù)據(jù)量逐漸增多時，差異就愈加明顯。目前測單表1000w已經(jīng)出現(xiàn)10%左右的性能損耗，如果單表數(shù)據(jù)繼續(xù)增大，性能損耗應(yīng)該也會更多。
以上就是MySQL運(yùn)行在docker容器性能損失解析的詳細(xì)內(nèi)容，更多關(guān)于MySQL docker性能的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
這篇文章主要介紹了MySQL 權(quán)限控制詳解的相關(guān)資料，幫助大家更好的理解和學(xué)習(xí)使用MySQL，感興趣的朋友可以了解下2021-03-03
之前被要求開發(fā)一個OA項目,需求還要及時生效（一邊開發(fā)一邊使用）,有一次生產(chǎn)環(huán)境的一個bug本地沒辦法復(fù)現(xiàn),在調(diào)試的過程中,我倆當(dāng)作開發(fā)環(huán)境很自然的把數(shù)據(jù)給刪了,所以在這里記錄一下MySQL數(shù)據(jù)備份和恢復(fù)的方法及操作,希望可以幫助到跟我一樣的小伙伴2024-01-01
這篇文章主要介紹了mysql如何修改表中某個數(shù)據(jù)的實現(xiàn)方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-08-08
這篇文章主要介紹了Mysql中如何刪除某個字段的最后四個字符，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-09-09
mysql開啟遠(yuǎn)程連接(mysql開啟遠(yuǎn)程訪問)
開啟MYSQL遠(yuǎn)程連接權(quán)限的方法，大家參考使用吧2013-12-12
MySQL參數(shù)lower_case_table_name的實現(xiàn)
lower_case_table_names是一個重要的系統(tǒng)變量,它影響著MySQL如何處理表名的大小寫,本文主要介紹了MySQL參數(shù)lower_case_table_name的實現(xiàn),感興趣的可以了解一下2024-08-08
MySQL服務(wù)器進(jìn)程CPU占用100%的解決方法
早上幫朋友一臺服務(wù)器解決了 Mysql cpu 占用 100% 的問題。稍整理了一下，將經(jīng)驗記錄在這篇文章里。2010-12-12
MySQL:reading initial communication packet問題解決方法
網(wǎng)站訪問出現(xiàn)如題錯誤，經(jīng)過檢查my.cnf，發(fā)現(xiàn)innodb_buffer_pool_size = 2048M 設(shè)置過大，調(diào)整為innodb_buffer_pool_size = 1024M即可，網(wǎng)上也有該問題的其他解決方法，但都不能解決我的問題2012-07-07
MySQL多版本并發(fā)控制MVCC深入學(xué)習(xí)
這篇文章主要介紹了MySQL多版本并發(fā)控制MVCC，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2021-11-11
前幾篇文章介紹了用源碼的方式來調(diào)試鎖相關(guān)的信息，這里同樣用這個工具來解決一個線上實際的死鎖案例，下面小編來簡單介紹下2019-05-05