MySQL基礎建設之硬盤篇 html
隨着業務的不斷增加,以前的環境愈來愈亂,由此欲重建整個MySQL數據庫基礎環境ios
主要目的是要考慮 數據冗餘、性能、平衡 目的是讓機器的性能最大的發揮,同時比較好維護算法
1、硬件選型數據庫
1.節點統計api
目前已將各庫進行分隔,但因爲每臺機器都過老過保,業務穩定可是硬件問題多多,出於節約成本,將機器數合併至兩臺數據庫上緩存
2.數據量統計服務器
出於規劃硬盤空間,需將每臺機器所佔用的data數據、binlog、slow log 及近期備份的日誌文件總和一一列出,以下所示併發
某機房ide |
||||
功能業務工具 |
data空間使用狀況 |
slow log空間使用狀況 |
bin_log目錄使用狀況 |
|
某同步系統|主庫 |
192G |
4.9G |
3.2G |
|
某同步系統|從庫 |
281G |
43M |
3.2G |
|
某api服務|主庫 |
6.2G |
300M |
3G |
|
某api服務|從庫 |
6.6G |
13M |
3G |
|
綜合業務服務|主庫 |
2.9G |
2M |
4.8G |
|
綜合業務服務|從庫 |
1.4G |
92M |
3.2G |
|
帳號服務 | 主庫 |
4.7G |
207M |
44G |
|
帳號服務 | 從庫 |
43G |
1M |
58M |
|
積分服務 | 主庫 |
1.5G |
200M |
11G |
|
積分服務 | 從庫 |
2.2G |
20M |
11G |
|
遊戲 | 主庫 |
1.4G |
1.8G |
753M |
|
遊戲 | 從庫 |
1.4G |
115M |
776M |
|
微博業務 | 主庫 |
2.0G |
2.5G |
674M |
|
微博業務 | 從庫 |
5.5G |
8G |
661M |
|
3.硬件選型
總結以上對容量進行相加,能夠算出單臺機器600G容量就足夠,可是考慮到之後幾年的擴容狀況,這裏使用2T的空間,稍後會介紹到
最終,服務器選擇了DELL R420;硬盤選擇了Crucial M550 ,具體能夠看其參數,價格就不要關注了:
本文來自 http://yijiu.blog.51cto.com 盜貼 可恥
M550官方說明 http://www.edgememory.com/ssds.aspx
聽說理論上iops能達到7w+ 那麼下面就來試試
2、一個坑:壓力測試
1.壓測工具選擇
這裏使用的是Fio,也能夠是其餘壓測工具,因我的喜愛而異
系統作好了,分別作了兩個不一樣的RAID級別,一個是RAID1 一個是RAID0
在網上搜索了一通,看別人都這麼作的,因此這裏也跟着學了直接複製,但是網上的文章坑不少
不要模仿,以前就是直接複製
順序寫:
fio -name iops -rw=write -bs=4k -runtime=60 -iodepth 32 -filename /dev/sdb1 -ioengine libaio -direct=1
隨機寫:
fio -name iops -rw=randwrite -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda1 -ioengine libaio -direct=1
隨機讀:
fio -name iops -rw=randread -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda1 -ioengine libaio -direct=1
本文來自 http://yi jiu.bl og.51ct o.com 盜 貼 可恥
那麼用fio來進行RAID0的壓測,使用隨機寫的方式得出結果:
[root@localhost io_test]# fio -filename=/io_test/test -iodepth=64 -ioengine=libaio -direct=1 -rw=randwrite -bs=4k -size=500G -numjobs=64 -runtime=20 -group_reporting -name=test-rand-writell
test-rand-writell: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
...
fio-2.1.10
Starting 64 processes
test-rand-writell: Laying out IO file(s) (1 file(s) / 512000MB)
Jobs: 30 (f=30): [_wwww_w__www______ww___ww___ww_w__ww__ww_w_wwww_w_w_w______w__ww] [3.3% done] [0KB/70497KB/0KB /s] [0/17.7K/0 iops] [eta 11m:20s]
test-rand-writell: (groupid=0, jobs=64): err= 0: pid=4305: Wed Apr 8 00:49:59 2015
write: io=1452.2MB, bw=74239KB/s, iops=18559, runt= 20028msec
slat (usec): min=15, max=80419, avg=3437.87, stdev=8530.70
clat (msec): min=1, max=747, avg=216.14, stdev=107.04
lat (msec): min=1, max=755, avg=219.57, stdev=108.24
clat percentiles (msec):
| 1.00th=[ 6], 5.00th=[ 30], 10.00th=[ 69], 20.00th=[ 126],
| 30.00th=[ 161], 40.00th=[ 190], 50.00th=[ 217], 60.00th=[ 243],
| 70.00th=[ 269], 80.00th=[ 306], 90.00th=[ 355], 95.00th=[ 396],
| 99.00th=[ 474], 99.50th=[ 506], 99.90th=[ 578], 99.95th=[ 603],
| 99.99th=[ 693]
bw (KB /s): min= 115, max=38223, per=1.54%, avg=1141.21, stdev=1116.54
lat (msec) : 2=0.55%, 4=0.11%, 10=1.68%, 20=1.63%, 50=3.58%
lat (msec) : 100=7.34%, 250=47.92%, 500=36.62%, 750=0.58%
cpu : usr=0.24%, sys=1.88%, ctx=424437, majf=0, minf=1842
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.3%, 32=0.6%, >=64=98.9%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued : total=r=0/w=371717/d=0, short=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
WRITE: io=1452.2MB, aggrb=74239KB/s, minb=74239KB/s, maxb=74239KB/s, mint=20028msec, maxt=20028msec
Disk stats (read/write):
sda: ios=0/371765, merge=0/13948, ticks=0/2776215, in_queue=2776513, util=99.24%
IOPS只有1.8W ,那麼須要考慮的爲啥只有1.8W 那麼繼續往下看
本 文來 自 ht tp://y ijiu.bl og.51 cto .com 盜 貼可恥
2.壓測工具命令各參數
上面涉及到了FIO,但是好多地方容易被忽略,那麼下面就來解釋一下之間的參數關係
涉及命令:
fio -filename=/io_test/test -iodepth=64 -ioengine=libaio -direct=1 -rw=randwrite -bs=4k -size=500G -numjobs=64 -runtime=20 -group_reporting
涉及參數解釋
Filename 測試文件名稱,一般選擇須要測試的盤的data目錄。
iodepth IO深度
-ioengine=libaio 使用libaio模式
direct=1 測試過程繞過自身緩存
bs=4k 單次io的塊文件大小爲4k
numjobs=64 本次的測試線程爲64
那麼知道各參數都是什麼做用了,接下來就須要瞭解硬件各之間的關係了,知道之間怎麼去調度的才能夠明白壓測的實際意義
3、緩存、深度及併發
1.緩存
緩存就不解釋了。以前聽到好多人說壓測的時候文件必需要大,實際上是錯誤的,首先來看 -bs=4k,因此這裏是在測試4k 的文件,而當時的內存是80G,一般只要測試到比 80G 多就能夠體現出性能了,可是這裏有一個direct=1的參數所在,那麼咱們不須要這麼大的文件進行壓測, 500G有點浪費磁盤壽命,在直接跳過緩存以後,80G 都是沒有必要的了,可是有必要寫入2G-10G 左右, RAID卡自己就有緩存的功能,因此,只須要大於這個緩存自己就好了,因此寫入2G能夠保證,已經開始越過 H710P 的cache。節約時間,節省使用壽命。
2.IO深度和併發
在這個測試裏面 蠻重要的一個參數是 -iodepth 64
首先要肯定 iodepth 應該走到多少,纔會有一個合理的結果,要從 iodepth 究竟是影響哪些層面去分析,CPU仍是內存仍是其餘?
#接下來能夠試着作一個 4 併發 和 一個 8併發的測試來查看結果,能夠自行測試,再也不放結果了
direct若是是影響 CPU 的話,那麼應該是數字越小,CPU消耗越大。由於數字越小,CPU 要批量往硬盤發數據的次數就是越多,可是數字越大,積壓的內存理論上應該越多
同時,硬盤一次能接收的數量老是有個極限的,因此應該是接近這個極限比較好,具體這麼極限怎麼計算,可能很難。可能要考慮到 CPU 內存,硬盤緩衝等一系列因素
知道以上的結論,接下來就不斷調整深度和併發數進行測試就行了
4、RAID卡特性
採購陣列卡的時候必須瞭解其特性,在官方 Guide 文檔裏面 15 頁有詳細介紹
首先是SSD的產品介紹
http://www.edgememory.com/ssds.aspx
RAID陣列卡的產品介紹
http://www.dell.com/learn/us/en/04/campaigns/dell-raid-controllers?c=us&l=en&s=bsd&cs=04&redirect=1
明白之間的管理又查閱了老外的資料幾個鏈接比較符合目前的狀況
http://blog.xbyte.com/author/lyndsieezell/page/2/
有句話須要特別注意:
For 2 and 4 disk arrays, performance for 100% sequential I/O was improved by utilizing FastPath.
在2塊和4塊盤的陣列裏面,配置 FastPath 會帶來 IO 方面 100% 的性能提高
1、參考其餘人的壓測經驗
這裏不得不說一下,做者使用了RAID10來作壓力測試,前期iops達到了2.6W,這裏提到了 發現了H710P的FastPATH功能,專門爲SSD的使用
前沿部分最後提到:
壓測真實數據只有60% 隨機,其餘都爲順序壓測
最後提到最主要的是須要明白使用什麼樣的IO調度方式,這裏我理解爲文件系統層面的io調度方式
本 文來 自 htt p:/ /yiji u.blog.51cto.com 盜貼 可恥
如下爲RAID 5 和 RAID10的壓測結果
RAID10的壓測結果以下:
6塊SSD作的RAID10可能會致使性能的降低,建議使用較少的磁盤數量比數量多的更佳
對於長期頻繁讀寫,較大數量的RAID陣列(理解爲4塊以上爲較大);容量更小的SSD的可能更有意義(老外反覆提到)
RAID 5 的壓測結果
在壓測中,總結:對於較大的陣列,在FastPATH工做中,FastPATH是否禁用後性能是否有影響,須要進行實際測試;由於它須要將一塊磁盤拿出來作奇偶校驗,因此可能會進行頻繁的調度
可是如圖上所顯示,RAID 5 在後期可能會略有降低
本文來 自 h ttp :/ /yijiu.blog .51c to.com 盜 貼~可恥
最後做者又提到,若是使用raid5作讀寫工做都很是頻繁的場景下建議使用多塊小硬盤
對於io負載較高的場景下,最好是使用容量大的SSD,以及數量較少的RAID的陣列;這裏能夠理解爲4塊盤以內的RAID陣列包括4塊盤
最後說明:在RAID 1/10和5使用SSD表現良好,可是出於實際考慮,須要確保是否符合當前的負載狀況,不能盲目選型,否則可能沒法達到預期的性能
第二篇文檔也明確提到以上觀點
http://www.cnblogs.com/ylqmf/archive/2013/02/28/2936895.html
在對RAID 0 的陣列上使用bs=4k 的隨機讀測試,只有128kb的效果比較明顯,比以前提升了24%.與4kb的小小相比,單塊盤的RAID 0 效率要高41%
文中提到未壓縮的壓測結果:
設置的CrystalDiskMark默認模式,主要用於不壓縮數據
在沒有壓縮數據的順序讀寫的測試中,順序讀最快的性能與更小的bs來實現,使用4k比 128k的性能高11% ,順序寫測試高於單塊硬盤的283%的性能;
512kb壓測對比
隨機讀寫
最快的size 爲8kb ,比單盤性能要高出 74% -- 88%
在隨機測試中,全部szie大小的性能都差很少,但都遠高於單塊盤。
在測試RAID 0兩個隨機讀取寫測試中,無論多少size爲4kb塊沒有任何優點
在順序讀寫,以及在 512 kiB 塊的隨機測試,RAID 0的單塊盤的性能比典型的RAID 0性能提升了80% - 324%
總結:
文中做者經過對比得出,size大小,大小其實不重要,只要高於自己緩存;若是場景是比較大文件的傳輸或者是須要大量壓縮文件的場景,能夠選擇128kib的大小配置,若是不是,可使用任意值; 所以,文章中又提到,不是採用了單塊大容量的SSD,而是選擇了兩個小容量的ssd作爲RAID 0 效果會更佳,(這裏也提到了用容量小的SSD作RAID效果會更好)
並且以上的文章反覆都提到了FASTPATH這個功能,那麼下面將其功能開啓再試試
5、設置FastPATH
1.FastPATH的做用
涉及資料:官方手冊,以下所示
咱們知道了咱們的RAID卡是支持FastPATH的功能的,那麼接下來要設置FastPATH功能
本文來 自 ht~t p://yi~ji~u.bl~og.51~cto.co~m ~盜貼 可恥
2.開啓FastPATH
FastPATH 默認爲開啓狀態;主要做用爲直接寫入緩存和不進行預讀操做
Fastpath I/O (H710P and H810 only)
Fastpath I/O is a method of increasing Input/Output Operations per Second (IOPS) by using the 2nd core of the PERC (Gemini core) to directly execute I/O and completely bypass caching.
Fastpath I/O is most beneficial for SSD disks.
Fastpath I/O is not available on H710 controller, only available on H710P and H810 controllers.
Fastpath I/O is automatically available on eligible VDs.
Fastpath eligible VDs should have the following properties:
Write-Through
No Read Ahead
No Background Operation (e.g. Background Initialization, Patrol Read or Consistency Check ) in progress.
服務器重啓,ctrl+r進陣列卡中選擇對應的VD,而後按enter鍵查看write policy 和read policy 並設置以上選項
先彆着急配置,這裏有涉及到兩個知識點:
Write-Through #設置爲直接寫
No Read Ahead #設置爲非預讀
本文來自 http://y ~iji~u.bl og.51cto.com 盜貼可恥
3.回寫、直寫和預讀、非預讀
關於write back 和Write Through
默認爲回寫的方式,對於某些數據模式和配置,直寫會得到更好的性能
回寫、Write Back
主要利用陣列卡的內存,進行緩存,而後sync到磁盤
直寫、Write Through
主要是將傳遞的數據不經過raid陣列卡的緩存,直接寫入到磁盤中,關閉寫緩存,可釋放緩存用於讀操做
預讀:
在沒有系統的IO請求的時候事先將數據從磁盤中讀入到緩存中,而後在系統發出讀IO請求的時候,就會實現去檢查看看緩存裏面是否存在要讀取的數據,若是存在(即命中)的話就直接將結果返回
若是禁用非預讀的話,則直接去硬盤中讀取數據
那麼明白以上兩點,設置RAID以下圖所示:
本文來 自 ht~t p://yi~ji~u.bl~og.51~cto.co~m ~盜貼 可恥
6、埋坑:仍是壓力測試
瞭解了上面全部的知識點及之間的調度關係,接下來再進行壓力測試,可是有個地方很擔憂,當發壓力的時候,是否磁盤還沒走到頂,CPU 已經走到頂了。這裏藉助了zabbix進行對系統進行監控 將出更新設置爲1秒一次,由於只有2臺機器
本文來 自 ht~t p://yi~ji~u. bl~og .51~cto.co~m ~盜貼 可恥
進行64 iodepth 的隨機寫和順序寫,結果以下:
進行了4個線程,隨機寫分別都是5200,4線程以4kb的寫入,那就是一共 28k
平均下來 隨機讀的iops,68000左右。那麼與官方手冊上說明的是一致了
壓測結果統計 |
|
讀/寫 |
IOPS |
隨機寫 |
5200 |
順序寫 |
18512 |
隨機讀 |
68000 |
以上只對RAID1進行說明,具體怎樣還須要實際去測試
7、RAID選型
通過上面對FastPATH的瞭解,接下來選擇合適的RAID類型
1.FastPATH特性及生效範圍
官方手冊15頁明確說明,對於如下生效的行爲都有標註,以下所示
就是說,以目前的狀態來看,只有RAID5和RAID1二者能夠選擇了
2.選型
以上,還在糾結於RAID1仍是RAID5
持FastPATH,跟RAID1同樣只對讀有性能的提升,可是RAID5會用其中一塊盤作奇偶校驗,若是是讀的話應該沒有影響,可是寫的話可能不如RAID1 ,由於以前看那兩篇壓測的文章上明確說明會有一層調度算法進行奇偶校驗。因此目前比較好的就是RAID1了
最終選擇了RAID1,服務器上爲4塊硬盤,分別作了2個RAID1
本 文來 自 ht~t p://yi~ji~u.bl~og.51~ct~o.co~m ~盜貼 可恥
8、壽命問題
以RAID5的角度來講,SSD 的壽命受限於寫的次數。RAID 每次都會多寫一份,可是 RAID 1 也會。
咱們的硬盤是 M550,質保是3年。如今的頁面我已經找不到 M550 的寫入壽命了,以前有篇文檔說這款硬盤的壽命應該是 120萬次
假設咱們作 RAID 5 ,因而壽命減半(不肯定是否會減半,可是確定會減小),那就是 60萬次。
如今目前960G 的硬盤,假設咱們有 900G 做爲數據存儲空間。60 萬次 也就是 514 EB 的總寫入量,平分到到三年質保期,每一天要寫入 大約 481 TB(應該沒算錯)的量這個硬盤纔會壞。因此壽命問題應該不是咱們擔憂的了。