文章來源地址http://www.zghlxwxcb.cn/news/detail-699346.html

1.?從軟件本身和它運(yùn)行的典型工作負(fù)載來看，MySQL通常也更適合運(yùn)行在廉價(jià)硬件上

2.?基本資源

2.1.?CPU

2.2.?內(nèi)存

2.3.?磁盤

2.4.?瓶頸

2.5.?網(wǎng)絡(luò)資源

3.?CPU

3.1.?最常見的瓶頸是CPU耗盡

3.2.?檢查CPU使用率來確定工作負(fù)載是否受CPU限制

3.3.?低延遲（快速響應(yīng)時(shí)間）

3.3.1.?需要更快的CPU，因?yàn)槊總€(gè)查詢將只使用一個(gè)CPU

3.4.?高吞吐量

3.4.1.?如果可以同時(shí)運(yùn)行多個(gè)查詢，那么可以使用多個(gè)CPU為查詢提供服務(wù)

4.?內(nèi)存

4.1.?內(nèi)存耗盡的情況也會發(fā)生，但通常只在你試圖將太多內(nèi)存分配給MySQL時(shí)才會發(fā)生

4.2.?配置大內(nèi)存的主要原因并不是為了在內(nèi)存中保存大量數(shù)據(jù)，而是為了避免磁盤I/O

4.3.?磁盤I/O比訪問內(nèi)存中的數(shù)據(jù)要慢幾個(gè)數(shù)量級

4.4.?如果有足夠的內(nèi)存，可以完全避開磁盤讀取操作

4.5.?如果所有數(shù)據(jù)都能裝入內(nèi)存，那么一旦服務(wù)器的緩存預(yù)熱完成，每次讀取都將是一次緩存命中

4.6.?寫入可以像讀取一樣在內(nèi)存中執(zhí)行，但遲早必須被寫入磁盤，才能持久保留數(shù)據(jù)

4.7.?緩存可以延遲寫操作，但緩存不能像消除讀操作那樣消除寫操作

4.8.?多次寫操作，一次刷新

4.8.1.?一個(gè)數(shù)據(jù)片段可以在內(nèi)存中被多次更改，而無須每一次都將新值寫入磁盤

4.8.2.?當(dāng)數(shù)據(jù)被最終刷新到磁盤時(shí)，自上次物理寫入以來發(fā)生的所有修改都將被持久化

4.9.?I/O合并

4.9.1.?許多不同的數(shù)據(jù)片段可以在內(nèi)存中被修改，這些修改可以被收集在一起，因此物理寫可以作為單個(gè)磁盤操作執(zhí)行

4.9.2.?提前寫日志（write-ahead logging）策略

4.9.2.1.?允許在內(nèi)存中更改頁面，而不用將更改刷新到磁盤，這通常涉及隨機(jī)I/O，速度非常慢

4.9.2.2.?將更改的記錄寫入順序日志文件，這樣要快得多

4.9.2.3.?后臺線程可以稍后將修改過的頁面刷新到磁盤，這樣做可以優(yōu)化寫操作的性能

4.10.?寫操作從緩沖中獲益，因?yàn)榭梢詫㈦S機(jī)I/O轉(zhuǎn)換為順序I/O

4.11.?異步（緩沖）寫操作通常由操作系統(tǒng)處理，并且是被成批處理的，因此可以更優(yōu)地被刷新到磁盤

4.12.?同步（無緩沖）寫入必須等待數(shù)據(jù)落盤

5.?固態(tài)（閃存）存儲

5.1.?I/O飽和也會發(fā)生，但比CPU耗盡的頻率低得多

5.2.?用HDD硬盤時(shí)，最好嘗試找到一個(gè)有效的內(nèi)存/磁盤比率

5.2.1.?HDD延遲較高、IOPS較低

5.3.?使用SSD時(shí)，內(nèi)存對磁盤的比率就變得不那么重要了

5.4.?固態(tài)設(shè)備對于提高服務(wù)器整體性能非常有用，現(xiàn)在通常應(yīng)該成為數(shù)據(jù)庫的標(biāo)準(zhǔn)配置，尤其對于OLTP工作負(fù)載

5.4.1.?SSD通常比HDD快10到20倍

5.4.2.?只有在預(yù)算極為有限的系統(tǒng)中，或者在需要驚人的高達(dá)數(shù)PB的磁盤空間的數(shù)據(jù)倉庫場景下，才考慮繼續(xù)使用HDD

5.5.?比硬盤驅(qū)動器明顯更好的隨機(jī)讀寫性能

5.6.?閃存設(shè)備讀的能力通常略好于寫的能力

5.7.?比硬盤驅(qū)動器更好的順序讀寫性能

5.8.?比硬盤驅(qū)動器更好的并發(fā)支持

5.8.1.?只有在擁有大量并發(fā)性的情況下，閃存設(shè)備才能真正實(shí)現(xiàn)最高吞吐量

5.9.?固態(tài)存儲設(shè)備使用非易失性閃存芯片組成的單元

5.9.1.?非易失隨機(jī)訪問內(nèi)存（NVRAM）

5.10.?固態(tài)存儲建立在閃存之上

5.11.?閃存的特點(diǎn)

5.11.1.?可以被快速地多次讀取，而且以很小的單元讀取數(shù)據(jù)

5.11.2.?寫入則要困難得多

5.11.2.1.?只有進(jìn)行特殊的擦除操作之后，存儲單元才能被重新寫入數(shù)據(jù)，并且每次擦除的塊大小較大

5.12.?寫操作的限制是固態(tài)存儲復(fù)雜性的原因

5.12.1.?為了使寫操作能夠很好地執(zhí)行，并避免過早地耗盡閃存塊寫壽命，設(shè)備必須能夠重新定位頁面，并執(zhí)行垃圾收集和所謂的損耗均衡

5.13.?為了使某些塊保持新鮮并為新的寫入做好準(zhǔn)備，設(shè)備會回收塊

5.14.?100GB文件在160GB的SSD上的性能與在320GB的SSD上的性能是不同的

5.14.1.?當(dāng)沒有空閑塊時(shí)，必須等待擦除操作完成，從而導(dǎo)致速度減慢

5.14.2.?寫入空閑塊需要幾百微秒，但擦除速度要慢得多，通常需要幾毫秒

6.?RAID

6.1.?存儲引擎通常將數(shù)據(jù)/索引保存在單個(gè)大文件中，這意味著RAID通常是存儲大量數(shù)據(jù)的最佳選項(xiàng)

6.2.?不要認(rèn)為RAID是數(shù)據(jù)安全方面的強(qiáng)有力的保證

6.2.1.?RAID并不能消除，甚至不能減少備份的需要

6.3.?保存在損壞的物理媒介中的數(shù)據(jù)很少被訪問，可能幾個(gè)月都不會被發(fā)現(xiàn)，直到嘗試讀取數(shù)據(jù)，或者當(dāng)另一個(gè)驅(qū)動器出現(xiàn)故障，RAID控制器嘗試使用損壞的數(shù)據(jù)重建陣列時(shí)才發(fā)現(xiàn)問題

6.3.1.?硬盤空間越大，出現(xiàn)這種情況的可能性就越大

6.4.?大多數(shù)控制器都提供了一些軟件來報(bào)告陣列的狀態(tài)，你需要對此進(jìn)行跟蹤，否則可能完全不知道驅(qū)動器已出現(xiàn)故障

6.4.1.?到第二個(gè)驅(qū)動器出現(xiàn)故障時(shí)就太晚了

6.5.?通過定期主動檢查陣列的一致性，可以降低潛在的損壞風(fēng)險(xiǎn)

6.6.?很多RAID控制器不能很好地處理大數(shù)據(jù)塊

6.7.?RAID緩存是物理安裝在硬件RAID控制器上的（相對）少量內(nèi)存

6.7.1.?在RAID緩存中緩存讀取都是浪費(fèi)內(nèi)存

6.8.?RAID控制器的內(nèi)存是一種稀缺資源，應(yīng)該明智地使用它

6.9.?對事務(wù)日志發(fā)出fsync()調(diào)用，并在啟用sync_binlog的情況下創(chuàng)建二進(jìn)制日志，但除非控制器有備用電池單元（BBU）或其他非易失性存儲，否則不應(yīng)啟用寫緩存

6.9.1.?硬盤也可能會撒謊。應(yīng)該確保在fsync()時(shí)刷新緩存，或者干脆在沒有備用電池時(shí)禁用它們

6.9.2.?當(dāng)安裝新硬件時(shí)，最好進(jìn)行真正的暴力碰撞測試（例如把電源插頭拔出來）。這通常是發(fā)現(xiàn)細(xì)微的錯(cuò)誤配置或偷偷摸摸的硬盤行為的唯一方法

6.10.?要測試RAID控制器的BBU是否真的可靠，請確保將電源線拔下一段時(shí)間

6.10.1.?有些BBU設(shè)備在沒電的情況下無法維持足夠的時(shí)間（將RAID緩存的數(shù)據(jù)刷新到磁盤

6.10.2.?一個(gè)環(huán)節(jié)出問題可能會導(dǎo)致整個(gè)存儲系統(tǒng)鏈變得無用

6.11.?RAID 0

6.11.1.?最便宜和性能最好的RAID配置

6.11.2.?永遠(yuǎn)不適合用于生產(chǎn)數(shù)據(jù)庫

6.11.3.?在開發(fā)環(huán)境中，當(dāng)服務(wù)器完全失效也不會變成突發(fā)事件時(shí)，可以選擇RAID 0

6.11.4.?不提供任何冗余

6.11.5.?RAID 0陣列的故障概率高于任何單磁盤的故障概率，而不是更低

6.12.?RAID 1

6.12.1.?良好的讀性能，并且可以跨磁盤復(fù)制數(shù)據(jù)

6.12.2.?良好的冗余

6.12.3.?讀取速度略高于RAID 0

6.12.4.?順序?qū)懭氩恍枰S多底層磁盤就能執(zhí)行得很好

6.12.5.?需要冗余但只有兩個(gè)硬盤驅(qū)動器的低端服務(wù)器的典型選擇

6.12.6.?大多數(shù)操作系統(tǒng)都允許你輕松地創(chuàng)建軟件RAID 0和RAID 1卷

6.13.?RAID 5

6.13.1.?將數(shù)據(jù)分布在具有分布式奇偶校驗(yàn)塊的多塊磁盤上，以便在任何一塊磁盤出現(xiàn)故障時(shí)，可以從奇偶校驗(yàn)塊重建數(shù)據(jù)

6.13.2.?如果兩塊磁盤同時(shí)出現(xiàn)故障，整個(gè)卷將無法恢復(fù)

6.13.2.1.?丟失兩塊磁盤時(shí)會產(chǎn)生災(zāi)難性的后果

6.13.3.?RAID 5的可伸縮性不能超過10塊磁盤

6.13.4.?良好的RAID 5的性能在很大程度上依賴于RAID控制器的緩存，這可能與數(shù)據(jù)庫服務(wù)器的需求相沖突

6.14.?RAID 6

6.14.1.?允許你在承受兩次磁盤故障的情況下仍然能重建陣列

6.14.2.?計(jì)算額外的奇偶校驗(yàn)會使寫操作比RAID 5慢

6.15.?RAID 10

6.15.1.?一個(gè)非常好的數(shù)據(jù)存儲選擇

6.15.2.?條帶化的鏡像對組成，因此在讀寫方面都能很好地被擴(kuò)展

6.15.2.1.?最佳的條帶塊大小取決于工作負(fù)載和硬件

6.15.2.2.?對于隨機(jī)I/O來說，擁有較大的塊大小是很好的，因?yàn)檫@意味著可以從單個(gè)驅(qū)動器中滿足更多的讀取需求

6.15.3.?與RAID 5相比，它的重建速度快且容易

6.15.4.?以很好地在軟件中被實(shí)現(xiàn)

6.16.?RAID 50

6.16.1.?由條帶化的RAID 5陣列組成，如果有很多磁盤，它可以很好地兼顧RAID 5的經(jīng)濟(jì)性和RAID 10的性能

6.16.2.?主要用于非常大的數(shù)據(jù)集，如數(shù)據(jù)倉庫或非常大的OLTP系統(tǒng)

7.?網(wǎng)絡(luò)

7.1.?延遲和帶寬是網(wǎng)絡(luò)連接的限制因素

7.2.?網(wǎng)絡(luò)運(yùn)行不正常是主要的性能瓶頸

7.3.?數(shù)據(jù)包丟失是一個(gè)常見的問題

7.3.1.?即使是1%的丟失也足以導(dǎo)致性能顯著下降，因?yàn)閰f(xié)議棧中的各個(gè)層都會嘗試通過等待一段時(shí)間然后重新發(fā)送數(shù)據(jù)包等策略來解決問題，這會增加額外的響應(yīng)時(shí)間

7.4.?DNS解析異常中斷或緩慢成為一個(gè)致命弱點(diǎn)

7.4.1.?對于生產(chǎn)服務(wù)器來說，啟用skip_name_resolve是一個(gè)好主意

7.4.2.?當(dāng)MySQL收到連接請求時(shí)，它會同時(shí)進(jìn)行正向和反向DNS查找

7.4.3.?如果啟用skip_name_resolve選項(xiàng)，MySQL不會進(jìn)行任何DNS查找

7.4.3.1.?意味著用戶賬號在host列中只能有IP地址、“l(fā)ocalhost”或IP地址通配符

7.4.3.2.?host列中包含主機(jī)名的任何用戶賬號都將無法登錄

8.?文件系統(tǒng)

8.1.?文件系統(tǒng)是在數(shù)據(jù)庫中保證數(shù)據(jù)完整性的最低層

8.2.?Windows

8.2.1.?只有一個(gè)（NTFS）是真正可行的

8.3.?GNU/Linux

8.3.1.?大多數(shù)時(shí)候，給定的文件系統(tǒng)跟其他文件系統(tǒng)相比不會有明顯的差別

8.3.2.?只有在某些情況下，達(dá)到文件系統(tǒng)的處理極限時(shí)，例如，需要處理高并發(fā)性、處理許多文件、碎片，等等，不同文件系統(tǒng)的差異才會體現(xiàn)出來

8.3.3.?最好使用日志型文件系統(tǒng)，如ext4、XFS或ZFS

8.3.4.?建議使用XFS文件系統(tǒng)，并將交換率和磁盤隊(duì)列調(diào)度器設(shè)置為適合于服務(wù)器的值

8.4.?磁盤隊(duì)列調(diào)度器

8.4.1.?完全公平排隊(duì)，即CFQ（Complete FairQueuing）

8.4.2.?在MySQL的工作負(fù)載類型下，CFQ會導(dǎo)致非常糟糕的響應(yīng)時(shí)間，因?yàn)闀槐匾刈枞?duì)列中的一些請求

8.4.3.?不要使用CFQ，它可能會導(dǎo)致嚴(yán)重的性能問題

8.5.?內(nèi)存和交換

8.5.1.?給MySQL分配大量內(nèi)存后，它的表現(xiàn)最好

8.5.2.?InnoDB使用內(nèi)存作為緩存來避免磁盤訪問

8.5.2.1.?意味著內(nèi)存系統(tǒng)的性能會直接影響查詢的速度

8.5.3.?當(dāng)使用SSD時(shí)，性能損失不像使用HDD時(shí)那樣明顯

8.5.3.1.?仍然應(yīng)該積極地避免交換，即使只是為了避免不必要的寫操作，因?yàn)閷懖僮骺赡軙s短磁盤整體壽命

8.5.4.?更改存儲引擎讀寫數(shù)據(jù)的方式

8.5.4.1.?設(shè)置innodb_flush_method=O_DIRECT可以減輕I/O壓力

8.5.4.2.?該參數(shù)僅對InnoDB有效

8.6.?很多技巧都是特定于內(nèi)核版本的，所以要小心，特別是在升級時(shí)

8.7.?Linux剖析器perf是一個(gè)非常有用的工具，可以用它來檢查操作在系統(tǒng)級別發(fā)生的事情

到了這里，關(guān)于讀高性能MySQL（第4版）筆記04_操作系統(tǒng)和硬件優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！