MySQL 效能比較測試:MySQL 5.6 GA -vs- MySQL 5.5

來源:互聯網
上載者:User

標籤:blog   http   使用   strong   io   檔案   資料   for   

時間:2013年11月07日 ⁄ 分類: 資料庫技術文檔 ⁄   我要吐槽發評論

MySQL 5.6 GA 發布了,毫無疑問,這是 MySQL 最棒的一個版本。

如果你還不清楚 MySQL 5.6 版本一長串的新特性和改進內容,可以從這裡獲得瞭解。

而我這篇文章的主要目的則是效能的測試。

我使用 Sysbench workloads (Read-Only/Read-Write) 來測試。下面是我的測試環境:

硬體設定:

  • 伺服器 : 32核 bi-thread (HT) Intel 2300Mhz, 128GB RAM
  • 作業系統 : Oracle Linux 6.2
  • 檔案系統 : XFS mounted with "noatime,nodiratime,nobarrier,logbufs=8"
  • MySQL : 5.6-GA, latest 5.5
MySQL 配置:

 

#-------------------------------------------------- max_connections = 4000 key_buffer_size = 200M low_priority_updates = 1 sort_buffer_size = 2097152 back_log = 1500 query_cache_type = 0# files innodb_file_per_table innodb_log_file_size = 1024M innodb_log_files_in_group = 3 innodb_open_files = 4000 table_open_cache = 8000 table_open_cache_instances = 16# buffers innodb_buffer_pool_size = 32000M innodb_buffer_pool_instances = 32 innodb_log_buffer_size = 64M join_buffer_size = 32K sort_buffer_size = 32K# tune innodb_checksums = 0 innodb_doublewrite = 0 innodb_support_xa = 0 innodb_thread_concurrency = 0 innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT innodb_max_dirty_pages_pct = 50 innodb_use_native_aio =1 innodb_stats_persistent = 1 innodb_spin_wait_delay = 6 / 96# perf special innodb_adaptive_flushing = 1 innodb_flush_neighbors = 0 innodb_read_io_threads = 16 innodb_write_io_threads = 4 innodb_io_capacity = 2000 innodb_purge_threads =1 innodb_adaptive_hash_index =  1 / 0# Monitoring innodb_monitor_enable = ‘%‘ performance_schema = ON performance_schema_instrument = ‘%=on‘#--------------------------------------------------

MySQL 調整:

  • 配置最主要的不同是 AHI (innodb_adaptive_hash_index) 和 Spin Delay (innodb_spin_wait_delay) -- 而其他的部分在這個測試過程中基本上已經足夠好了。
  • 關於 AHI 的影響我之前已經寫了很多文章。AHI 主要的困境在於“用還是不用”,在很多情況下它可以協助因為鎖導致的堵塞並加快索引的訪問,但在高並發的情況下可能會因為其 btr_search_latch 導致 rw鎖爭用導致的瓶頸
  • 在 MySQL 5.6 中的 Spin Delay 設定需要特別的注意,因為它在管理內部互斥量和 rw 鎖爭用時扮演非常重要的角色,利用它可能會讓你輕鬆的將效能提升一倍。(你可以通過這裡來瞭解詳情,但你應該知道,沒有銀彈,也沒有什麼固定的最優值是適合各種不同的環境,這個完全依賴於你的系統負載。因此其預設值跟 MySQL 5.5 一樣都是 6)。
  • 因此,在我的測試中,我非常好奇想瞭解在不同的負載情況下最佳的 AHI 和 Spin Delay 設定的配置對。
  • 接下來要記住 MySQL 5.5 和 5.6 在延展性方面的限制。我在 8、16、32 和 64 核的情況下重新進行測試(64核相當於開啟和超執行緒的32核機器,其他的都沒有開啟超執行緒)

首先向你展示第一個有趣的比較,為了跟我以前的測試保持“相容性”,我首先測試了 TPS (事務/秒),然後再是 QPS (查詢/秒) ,我更喜歡這種方式。

首個測試是經典的 Sysbench OLTP_RO (唯讀):

Sysbench OLTP_RO
 
接下來是同一個 OLTP_RO 測試,但在事務中不進行表的開啟和關閉操作 (完整的解釋請看 這裡 ) 

Sysbench OLTP_RO-trx : 
 

接下來是 "point-selects" ,這是一種讀資料的方式,在以前的 MySQL 5.5 版本表現良好,但在 5.6 仍有一些不同。

Sysbench OLTP_RO Point-Selects : 
 
這是最痛苦的測試,Simple-Ranges (你可以閱讀 此文 瞭解為什麼痛苦和令人沮喪) 

Sysbench OLTP_RO Simple-Ranges : 
 

下面是讀寫測試,這還不是負載最重的讀寫,但仍可說明問題:

Sysbench OLTP_RW : 
 
TPS 從 256 個並發使用者時就開始下降,期待這個有更高的水平。但仍然比 5.5 版本要高出 2 倍,相信我,下一個版本的 MySQL 表現會更好。這個階段可通過調整 innodb 線程並發設定來得到更穩定和更高效能。

 

我很高興的看到 MySQL 5.6 GA 發布,因為:

  • 這是 MySQL 史上最棒的版本
  • 在高負載下比 MySQL 5.5 快很多
  • 更好的設計
  • 更具可調節性
  • 效能分析更透明
  • 更好的儀錶化
  • 這些方式比你以往看到的都要好
  • 包含很多新特性

因此,我唯一的問題是:你什麼時候開始測試 MySQL 5.6 並制定資料庫移植計劃? 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.