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要做好備份機制，並隨時抽查備份的有效性。
