建站
咨詢
售后
建站咨詢
新聞中心
進(jìn)行測(cè)試的機(jī)器包含2個(gè)CPU共8核的處理器（這是我手頭上能找到最好的機(jī)器了）、10K SAS 磁盤（RAID1），使用sysbench 0.4測(cè)試單表共100萬行記錄。我通過網(wǎng)絡(luò)來運(yùn)行這個(gè)壓力測(cè)試，并發(fā)的客戶端從4到4096。
成都創(chuàng)新互聯(lián)是一家網(wǎng)站設(shè)計(jì)公司，集創(chuàng)意、互聯(lián)網(wǎng)應(yīng)用、軟件技術(shù)為一體的創(chuàng)意網(wǎng)站建設(shè)服務(wù)商，主營(yíng)產(chǎn)品：響應(yīng)式網(wǎng)站設(shè)計(jì)、高端網(wǎng)站設(shè)計(jì)、全網(wǎng)營(yíng)銷推廣。我們專注企業(yè)品牌在網(wǎng)站中的整體樹立，網(wǎng)絡(luò)互動(dòng)的體驗(yàn)，以及在手機(jī)等移動(dòng)端的優(yōu)質(zhì)呈現(xiàn)。成都做網(wǎng)站、網(wǎng)站制作、移動(dòng)互聯(lián)產(chǎn)品、網(wǎng)絡(luò)運(yùn)營(yíng)、VI設(shè)計(jì)、云產(chǎn)品.運(yùn)維為核心業(yè)務(wù)。為用戶提供一站式解決方案，我們深知市場(chǎng)的競(jìng)爭(zhēng)激烈，認(rèn)真對(duì)待每位客戶，為客戶提供賞析悅目的作品，網(wǎng)站的價(jià)值服務(wù)。
這里是 OLTP-只讀 吞吐量測(cè)試結(jié)果：
說明：
絕大多數(shù)的測(cè)試結(jié)果表明，MariaDB 的吞吐量比 MySQL 高出 10% 左右
在 4096 并發(fā)客戶端時(shí)，MariaDB 的吞吐量是 MySQL 5.5 的 四倍多 476% (2382 vs 413 TPS).
很多人理所當(dāng)然的認(rèn)為吞吐量并不能代表數(shù)據(jù)庫的整體性能表現(xiàn)。在OLTP的基準(zhǔn)測(cè)試中，響應(yīng)時(shí)間同樣很重要，實(shí)際上它比吞吐量更加重要，這點(diǎn)我同意，因此，下面是查詢的響應(yīng)時(shí)間，意味著 95% 的事務(wù)都在指定的時(shí)間內(nèi)處理完畢。
OLTP 只讀響應(yīng)時(shí)間
| 并發(fā)數(shù) | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1024 | 2048 | 4096 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| MariaDB | 4.87 | 6.81 | 8.83 | 12.35 | 22.12 | 43.56 | 90.35 | 180.57 | 619.05 | 1003.88 | 1965.77 |
| MySQL | 4.86 | 7.14 | 9.96 | 16.21 | 37.39 | 101.33 | 238.89 | 499.63 | 971.07 | 2241.83 | 25215.29 |
上表中顯示，MariaDB 5.5 不管是在吞吐量還是響應(yīng)時(shí)間方面都是優(yōu)于 MySQL 的。
但是，為什么MariaDB在Windows 下的只讀測(cè)試由于MySQL 5.5呢？二者基于同一個(gè)代碼，表現(xiàn)應(yīng)該也相同啊。這個(gè)問題的答案并不是 MariaDB 做了什么優(yōu)化，也無關(guān) XtraDB 和 InnoDB 的優(yōu)劣。答案是 MariaDB threadpool. 這個(gè)線程池在 Windows 平臺(tái)是默認(rèn)啟用的。
可是，為什么使用線程池就可以有如此好的性能呢？答案是 MariaDB 承擔(dān)了通過調(diào)整線程池的大小并回調(diào)到對(duì)應(yīng)的 Windows 本身的線程池，這在操作系統(tǒng)這一級(jí)別上相當(dāng)于黑盒排序，因此能獲取良好的性能。Windows 內(nèi)置的線程池的核心，是自 NT 3.5 就有的技術(shù)，這是 Windows 專有的特性，運(yùn)行在其上的服務(wù)器應(yīng)該使用這種技術(shù)。要讓這項(xiàng)技術(shù)運(yùn)行良好的招數(shù)是：
不要讓同一時(shí)間在同一個(gè)CPU上運(yùn)行太多的線程，這樣可減少上下文切換，這是提高吞吐量的最重要的因素
在完成的LIFO順序中激活線程等待，熱門的線程保持熱門，可降低緩存失效
順序處理 IO 完成，這是響應(yīng)時(shí)間表現(xiàn)良好的因素
最后便是降低熱鎖的爭(zhēng)用
由此，線程池是只讀性能表現(xiàn)佳的主要因素。
下一個(gè)有趣的問題是在寫操作上MariaDB表現(xiàn)是否一致。因此我們使用寫模式來運(yùn)行 sysbench 工具，也就是 update_non_index (每個(gè)查詢對(duì)一個(gè)非索引的整數(shù)字段進(jìn)行加值處理)。為了最大化寫的吞吐量，我們?cè)O(shè)置了參數(shù) innodb_flush_log_at_trx_commit 值為 0，每次日志的寫入是每秒一次，而不是每次事務(wù)提交一次。
測(cè)試結(jié)果如下：
OLTP write-only (update_non_index/flush_log=0) 吞吐量:
這個(gè)結(jié)果看起來很棒，差別來源于多個(gè)因素，包括 XtraDB 的寫性能、分組提交、線程池等都對(duì)這個(gè)結(jié)果會(huì)有影響。但我想Windows平臺(tái)下的 MariaDB 的 asynchronous IO optimization (異步 IO 優(yōu)化) 是最主要的因素。
在上述測(cè)試中，所有 IO 相關(guān)的參數(shù)和 InnoDB 參數(shù)都使用的是默認(rèn)值，結(jié)果看起來太好了以至于讓我們懷疑這是真的。我真的想通過調(diào)整為 innodb_io_capacity and/or innodb_write_io_threads 參數(shù)為 MySQL 帶來更加的性能，有人知道該如何調(diào)整嗎？
OLTP writeonly (update_non_index/flush_log=0) 響應(yīng)時(shí)間, 95 percentile
| 并發(fā)數(shù) | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1024 | 2048 |
|---|---|---|---|---|---|---|---|---|---|---|
| MariaDB | 0.33 | 0.63 | 0.75 | 1.06 | 1.94 | 3.85 | 8.25 | 21.38 | 129.79 | 274.40 |
| MySQL | 0.32 | 0.61 | 0.73 | 1.61 | 7.62 | 26.82 | 96.45 | 219.29 | 661.19 | 2723.36 |
下面是對(duì)數(shù)據(jù)庫的參數(shù)調(diào)整：
[mysqld]
sql-mode="NO_ENGINE_SUBSTITUTION"
back_log=500
user=root
port=3306
max_connections=4096
max_connect_errors=5000
max_prepared_stmt_count=50000
table_cache=2048
transaction_isolation=REPEATABLE-READ
loose-skip-external-locking
innodb_status_file=0
innodb_data_file_path=ibdata1:200M:autoextend
innodb_buffer_pool_size=1G
innodb_additional_mem_pool_size=20M
innodb_log_file_size=650M
innodb_log_buffer_size=100M
innodb_support_xa=0
innodb_doublewrite=0
innodb_flush_log_at_trx_commit=0
query-cache-size=0
query-cache-type=0
symbolic-links=0
skip-grant-tables
網(wǎng)頁名稱：MariaDB5.5在Windows下的性能測(cè)試
URL地址：http://www.dlmjj.cn/article/coghdos.html
