一.什麼決定雙11大促的成敗?
場景:原資料庫架構為1m15s,m伺服器效能很好,64核512g記憶體,io採用fushion io,比一般磁碟的讀寫能力高很多.
缺點:1.只有乙個主庫,沒有主從切換中介軟體,每次如果主庫掛了,需要運維人員手動進行切換,然後同步給其他從庫,耗時高(超過半小時不可用)
2.雙十一凌晨2點半資料庫磁碟io達到峰值,造成恐慌,擔心效能為急劇下降.經檢查,發現是資料庫遠端備份定時任務在跑,總結:最好不要在主庫上進行資料庫備份,大型活動前取消這類計畫.
對資料庫效能影響比較大的因素:
(1)sql效能
(2)網絡卡流量
(3)伺服器硬體
(4)磁碟io
(5)大表
(6)大事務
資料庫面臨的風險:
(1)超高的qps和tps
根據經驗,資料庫效能80%都是由慢查詢導致的.大多數據資料庫問題都可以通過sql效能優化來解決.
當前的mysql不支援單sql語句多cpu併發計算,一條sql只能由乙個cpu去執行.10ms的sql和100ms的sql效能直接相差10倍.
(2)大量的併發和超高的cpu使用率
大量併發:資料庫連線被佔滿.當併發數大於最大連線數時,出現500錯誤,對使用者體驗造成影響.
ps:併發數和連線數的區別:併發是指同時請求mysql的數量,連線數是指mysql的連線數,通常連線數遠大於併發數,因為大部分的連線都是出於sleep狀態.類似於http長連線.
資料庫最大連線數:max_connections,預設值為100.所以需要把這個引數改的大一些.
超高的cpu使用率:可能導致cpu資源耗盡而宕機
(3)磁碟
1.io效能突然下降
常發生在熱資料量遠遠大於伺服器可用記憶體的情況下(使用更快的磁碟裝置來解決.比如fashion io,ssd,更好的raid卡)
2.其他大量損耗磁碟效能的計畫任務(調整計畫任務,做好磁碟維護)
(4)網絡卡流量(1000mb/8≈100mb)
流量高峰期,千兆網絡卡多次被跑滿,其他請求會出現無法連線資料庫.
解決辦法:
1.減少從資料庫的數量
2.進行分級快取,避免大量的請求突然對資料庫形成衝擊
3.避免使用select * 進行查詢,查詢出沒有必要的列會浪費網路流量
4.分離業務網路和伺服器網路,避免主從同步或者備份等作業影響網路效能.
什麼是大表:
1.記錄行數巨大,單表達到千萬行
根據場景靈活應用,比如日誌表,只有insert操作和少量的select操作,幾乎沒有update操作和delete操作,這樣的表就算超過了千萬行,也不會對業務產生什麼影響.實際工作中有遇到過,日誌表的行數已經超過10個億了,一直很穩定.但是在增加列的時候,會非常痛苦(為什 麼?)
2.資料檔案巨大,表資料檔案超過10g
大表對查詢的影響:
1.慢查詢:大表意味著很難在一定的時間內,過濾出所需要的的資料
2.對ddl操作的影響
(1)建立索引需要花費很長的時間
mysql版本<5.5,建立索引會鎖表
mysql版本》=5.5,不會鎖表,但是會引起主從延遲
(2)修改表結構需要長時間鎖表
風險:1.會造成長時間的主從延遲.假設主庫修改需要480s,mysql5.6之前主從同步使用的是單執行緒,主庫執行完之後才會同步到從庫執行相同的操作,所以從庫也至少需要480s來完成同步,也就造成了480s的主從延遲,這對於大多數業務來說都是不可接受的.
5.6之後,支援多執行緒複製,但是也有一定的限制.
2.影響正常的資料庫操作(鎖表,其他操作被阻塞),導致資料庫連線數猛增.超過最大連線數後,前台出現500錯誤
如何解決大表問題:
1.分庫分表
2.進行歷史資料歸檔
難點:(1)歸檔是時間點的選擇
(2)如何進行歸檔操作(大表中刪除大量資料,需要注意方式方法,否則輕則造成主從延遲,重則影響使用者正常操作)
大事務對效能的影響
定義:執行時間較長,操作的資料比較多的事務
風險:鎖定太多的資料,造成大量的阻塞和鎖超時.
回滾時所需時間比較長(有可能比執行事務所花費的時間更長)
執行時間長,容易造成主從延遲
解決方法:
1.避免一次性操作太多的資料
2.移出不必要在事務中的select操作
影響效能的幾個方面:
1.計算機硬體,如cpu,記憶體,磁碟io
2.作業系統,windows xp系統預設的併發數只有10個.伺服器效能調優
3.mysql的儲存引擎
myisam:不支援事務,表級鎖
innodb:事務級儲存引擎,完美支援行級鎖,事務acid特性.
4.資料庫引數配置
有些引數對資料庫效能的影響是決定性的.
前面三個方面的影響加起來 < 資料庫引數配置的影響
5.資料庫表結構設計和sql語句執行效率
慢查詢是很多資料庫效能低下的罪魁禍首.
很多慢查詢是由於資料庫表結構設計不合理導致的,這類問題一旦專案上線就很難再修改了.
重點是前期的優化設計及後期sql優化.
如何選擇cpu?
1.高的頻率,更多的核心核心數.2者不可兼得時,web應用來說,核心數》頻率.cpu密集型應用來說,由於mysql不支援多核併發計算同一條sql,所以頻率也很重要.
2.mysql版本也有影響,5.0之前的版本對於多核cpu的支援是很弱的,5.6,5.7之後做了很好的支援.
3.注意不要出現64位的cpu使用32位的作業系統,大多由於誤裝,對效能限制很大.
如何選擇記憶體?
1.資料庫自帶快取策略,記憶體的大小直接影響資料庫效能,特別是當熱資料大小遠遠大於可用記憶體時.
myisam
索引->記憶體
資料->os
innodb
索引,資料->記憶體
2.記憶體並不是越大越好,當記憶體大小大於所有資料量大小,即所有的資料都已經被快取在記憶體中,再增加記憶體就是沒有意義的了.
3.記憶體的大小不僅對查詢有效,對插入也一樣有效.可以做到延緩插入,先快取在記憶體中,然後批量插入,從而減少io操作次數,提高效能.
4.頻率越高越好,選擇主機板能夠支援的頻率最高的記憶體條,然後單個記憶體條盡量的大,所有記憶體條型號保持完全一致.
磁碟的配置和選擇
1.使用傳統機器硬碟
最常見,使用最多,**低,儲存空間大,讀寫速度慢
如何選擇?
1.儲存容量
2.傳輸速度
3.訪問時間
4.主軸轉速(7500,15000)
5.物理尺寸(越小越快)
2.使用raid增強傳統機器硬碟的效能
定義:raid是磁碟冗餘佇列的簡稱,吧多個容量較小的磁碟組成一組容量更大的磁碟,並提供資料冗餘來保證資料完整性的技術
常見raid組別:
(1)raid 0:資料條帶,串聯,成本低,可以提高磁碟效能和吞吐量,沒有提供冗餘和錯誤修復.損壞率比單塊磁碟更高,其中任何一塊磁碟損壞都會造成數丟失.
(2)raid 1:磁碟映象,最大限度的保障可靠性和可修復性,磁碟利用率低(50%)
(3)raid 5:分布式奇偶校驗磁碟陣列,讀快,寫慢,磁碟利用率高,只需要額外一塊磁碟.同時損壞兩塊以上則不可修復.
(4)raid 10:先做raid 1,在做raid 0,讀寫效能好,恢復較raid 5更簡單,速度也更快.
3.使用固態儲存ssd和pcie卡
更好的隨機讀寫效能
更好的支援併發
缺點:更容易損壞
ssd:使用sata介面,同樣可以使用raid技術,由於頻寬的限制,無法完全發揮快閃儲存器技術的效能
pcie卡:無法使用sata介面,需要特殊的驅動和配置,**比ssd更貴,效能更好.fusion-io,會占用記憶體資源.
如果只有一塊ssd,應該放在從伺服器上,而不是主伺服器上.
4.使用網路儲存nas和san
san和nas是兩種外部檔案儲存裝置載入到伺服器上的方法
mysql效能優化配置總結
看了一些優化mysql運維的一些書籍，在此記錄總結下 進入mysql客戶端輸入以下sql 1 連線設定 show variables like max connection show status like max used connections max used connections max ...
mysql效能優化總結 四
mysql資料庫結構設計和sql優化 資料庫設計對效能的影響 1.過分的反正規化化設計為表建立太多的列 服務層和儲存引擎層之間通過反衝格式來拷貝資料和解析成列,列過多,帶來額外的cpu消耗 2.過分正規化化造成過多的表關聯,mysq最多支援61張表的關聯查詢,需要控制在10個以內 3.使用不恰當的分...
mysql效能優化總結 三
mysql體系結構 外掛程式式儲存引擎,將資料的查詢和儲存相分離.每一款儲存引擎都有各自的優缺點.可以靈活選用 架構 客戶端 mysql服務層 儲存引擎層 儲存引擎是針對表,不是針對庫,同一庫中的不同的表,可以使用不同的儲存引擎.但是不建議這樣做 儲存引擎的不同會對效能產生直接的影響.mysql常用...