簡介

通過sysbench的oltp_read_write測試來模擬業(yè)務(wù)壓力、以此來給指定的硬件環(huán)境配置一份比較合理的MySQL配置文件。

環(huán)境介紹

硬件配置

軟件環(huán)境

優(yōu)化層級與指導(dǎo)思想

優(yōu)化層級

MySQL數(shù)據(jù)庫優(yōu)化可以在多個不同的層級進行，常見的有：

SQL優(yōu)化參數(shù)優(yōu)化架構(gòu)優(yōu)化本文重點關(guān)注：參數(shù)優(yōu)化

指導(dǎo)思想

日志先行 -- 一個事務(wù)能否成功提交的關(guān)鍵是日志是否成功落盤，與數(shù)據(jù)沒有太大的關(guān)系；也就是說對寫的優(yōu)化可以表述為各方面的資源向?qū)懖僮鲀A斜。瓶頸分析 -- 通過show global status 的各個計數(shù)器的值基本上就能分析出當(dāng)前瓶頸所在，再結(jié)合一些簡單的系統(tǒng)層面的監(jiān)控工具如top iostat 就能明確瓶頸。整體性能是“讀”&“寫”之間的再平衡。

優(yōu)化過程

優(yōu)化前

my.cnf中的內(nèi)容(關(guān)鍵部分)

監(jiān)控數(shù)據(jù)

show global status 中Innodb_data_pending_fsyncs 這個status比較高；iostat的util項有比較明顯的波峰，峰值使用率高達85%；

監(jiān)控數(shù)據(jù)分析與優(yōu)化思路

對監(jiān)控數(shù)據(jù)有兩種可能的解釋：

由于最小化的安裝的buffer_pool_size比較小，所以會頻繁的觸發(fā)innodb_buffer_pool的最大臟頁的限制，使得innodb進入暴力刷盤的模式，這種情況下io使用率會明顯上升。redo日志重用。 最終的影響可能是兩者的疊加，這里先從buffer_pool開始優(yōu)化。

優(yōu)化緩沖池

my.cnf中的內(nèi)容(關(guān)鍵部分)

監(jiān)控數(shù)據(jù)

show global status 中Innodb_data_pending_fsyncs 這個status減小到了 1；iostat的util項峰值有所下降；從性能圖像可以看出增大innodb_buffer_pool_size的值后、性能的峰值所對應(yīng)的并發(fā)更高了(當(dāng)innodb_buffer_pool_size默認的128M調(diào)整到200G時innodb_buffer_pool_instances自動增大到了8)調(diào)整innodb_buffer_pool_size前后的性能對比

性能大概提高3倍

監(jiān)控數(shù)據(jù)分析與優(yōu)化思路

針對innob_buffer_pool_size的調(diào)整取得了一定的收獲，下面將要調(diào)整的就是針對redo重用的情況了，也就是說我們要增大innodb_log_files_in_group和innodb_log_file_size到一個合適的值。innob_buffer_pool_size取得的收獲還可以進一步擴大，那就是增大innodb_buffer_pool_instances的值。優(yōu)化日志文件

根據(jù)對之前測試的記錄每完成一組測試LSN增大4.5G、測試持續(xù)時間大概是5分鐘；理論上把redo文件增大到5G可以做到整個測試的過程中不發(fā)生日志重用、這樣的話測試的跑分會更高、曲也線更平滑，不過這個會影響數(shù)據(jù)庫宕機恢復(fù)的時間。MySQL在默認配置下innodb_log_files_in_group=2，innodb_log_file_size=48M也就是說跑完一組測試redo日志要刷新48輪(1024*4.5/96 ==48) 先看一下把日志刷新減少到9輪的情況。

my.cnf中的內(nèi)容(關(guān)鍵部分)

調(diào)整innodb_log_files_in_group&innodb_log_file_size前后的性能對比

性能大概提高2倍

現(xiàn)在看一下日志重用控制在一輪(5G)之內(nèi)的性能表現(xiàn)

my.cnf中的內(nèi)容(關(guān)鍵部分)

調(diào)整innodb_log_files_in_group&innodb_log_file_size前后的性能對比

性能大概提高2倍

監(jiān)控數(shù)據(jù)分析與優(yōu)化思路

增大redo到5G的情況下由于整個測試過程中幾乎沒有日志文件重用的問題，這樣也就規(guī)避由些引發(fā)的大量數(shù)據(jù)刷盤行為，所以性能曲線也就更平滑了。通過show global status 發(fā)現(xiàn)Table_open_cache_overflows=200W+、Thread_created=2k+%Cpus : 80.5 us, 13.8 sy, 0.0 ni, 5.4 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st 95%的使用率cpu資源成了大問題，這個使用率下能調(diào)整的參數(shù)不多了對磁盤的監(jiān)控數(shù)據(jù)表明util的峰值已經(jīng)下降到14%、磁盤已經(jīng)不在是問題；所以針對innodb_buffer_pool_size、innodb_log_files_in_group&innodb_log_file_size 這兩次優(yōu)化的進入一步優(yōu)化innodb_buffer_pool_instances、innodb_log_buffer_size 先不進行；在些采用“抓大放小”的方式先調(diào)整表緩存與線程緩存。

優(yōu)化其它已知項

cpu使用率達到了95%，看到這個數(shù)值有一種發(fā)自內(nèi)心的無力感，所以打算所目前status中能明確的一些問題直接一起調(diào)整了；增大table_open_cache&table_open_cache_instances用于優(yōu)化表緩存、增大thread_cache_size使cpu不用頻繁的創(chuàng)建銷毀線程。

my.cnf中的內(nèi)容(關(guān)鍵部分)

調(diào)整前后的比較

總結(jié)

一、考慮到cpu使用率已經(jīng)達到95%且增加物理cpu不現(xiàn)實的情況下，決定MySQL參數(shù)優(yōu)化到此為止；最后來看一眼這次優(yōu)化成果。

二、前面由于篇幅只給出配置文件的一部分、現(xiàn)在我們來看一下完整的配置文件。

說明

之所以max_prepared_stmt_count要調(diào)整到這么是因為sysbench的oltp_read_write這個測試會用于prepare語句、如果這個值不夠大的話我們測試不了800+并發(fā)，你測試sysbench其它oltp用例可能不用這么做，同理max_connections的配置也是如此(不過它確實設(shè)置的大了點)有些參數(shù)在優(yōu)化過程中我并沒有調(diào)整主要原因有兩個：①.這是有方法論指導(dǎo)的優(yōu)化、它更像定向爆破，所以沒用的我不去動、在關(guān)鍵參數(shù)上調(diào)整后已經(jīng)解決問題的情況下，其它相關(guān)的參數(shù)我更加傾向不動。②.對于從show global status 中能看出非常明確指向的我也會采取多個參數(shù)一起調(diào)整的策略。

總結(jié)

以上是生活随笔為你收集整理的mysql 需要什么硬件配置_如何来给指定的硬件环境配置一份比较合理的MySQL配置文件-爱可生...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。