MySQL資料庫單機load過高問題討論

MySQL單機load過高問題討論

 

有一個朋友問我: "hi,我想問下你們遇到單機load過高的情況 采取什麼緊急措施啊?"

我問他是不是mysql db server?

 

他說是。

我給他如下建議:

1 先看下是不是mysqld進程造成的load高?

2 如果是的話,去看下當前線程有沒有比較慢的sql

 

朋友再問: 嗯 都沒有呢,這個如果由於業務的原因導致load高呢

 

我給出自己的建議:

1  並發量過高

2 業務原因,是crontab 任務,可以停止就停止掉

 

朋友再問:不是 sql的原因啊 db機器一般出現load高都是因為io,cpu這些導致的 這些很大部分都是由於業務繁忙處理不過來吧

我回復 :

1 嗯,不是慢sql導致io cpu爆增的,我還沒碰到過,可能是我們這邊單機性能太好瞭, [做人要坦誠特別是技術討論]

2 如果是io,cpu,那也是有事務操作吧

3 看看db參數設置是否合理,如果參數合理的話,估計就是到瞭單機性能的瓶頸瞭

 

朋友問:額 沒有遇到過 …. 這,那沒有遇到過db機器load高需要處理的啊?

 

我回復:

遇到很多,大部分都是慢sql造成的

 

朋友再問:嗯 一般不急?

 

我回復:

1 嗯,不會啊,我們事先上應用之前都會做壓力測試,峰值測試

2 業務量不會超過預計的峰值

3 你們單臺load過高,現在mysql不都是多臺嗎?分佈式,讀寫負載均衡,一臺load過高,那另外幾臺呢?

 

朋友再問: 我假設某個業務 突然一天訪問量很高(超過之前預估),這個時候又隻訪問一個主,而業務肯定不能停的,機器明顯感覺處理不過來,load急速上升,有什麼辦法處理嗎?我們的不是不是分佈式的,現在的分佈式都有負載均衡,對這樣的情況太好處理瞭。

 

我回復:

1 這個時候業務不能停,單機硬件升級更不是可行方案。

2 在發現cpu過高瞭,就馬上去準備加新的db機器,如果新的db機器在單臺db爆掉之前準備好的話,直接添加上去,分擔app訪問壓力。

3 這個操作不會對業務產生影響,我們一般用的都是vip吧,在vip下再加一臺db,應該是很方便的。

 

朋友再問: 我在想這樣的問題還真是有點難處理啊?

 

我表示疑惑:為什麼,你們不是用vip訪問db?

朋友說:不是,都是直接寫真實ip上去連接應用的。

 

說道這裡,如果沒有vip,而且是單臺db,到時候瞬間爆掉瞭,我隻能表示我水平有限暫時也沒有別的好招瞭,隻有暫停業務並且重新架構db瞭。

不過我還是給他一些自己的建議,希望能帶給他一些幫組:

1 上新的app之前,做好db的壓力測試和峰值測試。

2  要做db的ha方案,並且測試通過。

3  db的ip已經app的ip已經要用類似vip的處理方式,以便方便擴展。

4  db要做好備份機制,並隨時抽查備份的有效性。

 

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *