mysql性能基準

Question

我在考慮將我們的生產環境從一個自我託管的解決方案轉移到亞馬遜aws。我看了一下不同的服務，並考慮使用RDS來代替我們的mysql實例。我們使用的硬件似乎比使用rds（Quadruple Extra Large數據庫實例）時所能獲得的最佳硬件要好。由於我不能簡單地將我們的製作環境轉移到aws，並且看看錶演是否還足夠好，我很樂意提前做一些測試。

我想過從我們當前的主服務器創建完整的查詢日誌，配置rds實例並開始重播完整的查詢日誌。實際上，我甚至不知道這種測試是否是一個好主意，但我想你會告訴我是否有更好的方法來確保在遷移到rds時，mysql的性能不會顯着下降。

1. 是否有重播完整查詢日誌的首選工具？
2. 在運行測試時應該查看哪些指標
   • cpu使用情況？
   • 內存使用情況？
   • 磁盤使用情況？
   • 查詢時間？
   • 什麼？

在此先感謝

Answer 1

我建議不要重播查詢日誌 - 它幾乎肯定不會給你你想要的信息，並會採取的努力顯著量。

首先，您需要準備數據庫，以便在插入，更新或刪除數據時重播查詢日誌不會中斷約束，並且隨後的「select」查詢將查找應找到的記錄。對於除玩具數據庫以外的其他任何東西，這顯然不是微不足道的 - 只需進行備份並重播日誌並不一定能保證DML語句的排序與生產中發生的事件相匹配。這可能會給你一種虛假的安慰感 - 所有的選擇語句都會在幾毫秒內返回，因爲他們正在查找的數據不存在！其次，負載和性能測試很少能夠通過回放生產中發生的事情來工作 - 這通常不會反映將使您的系統癱瘓的高峯狀況。例如，大多數生產系統在大多數情況下運行在50％的容量下，但是白天可能會達到80％或更高的容量 - 這就是你關心的問題，新環境能否處理高峯。

我的建議是使用像JMeter這樣的工具來編寫性能腳本（使用JDBC驅動程序直接寫入數據庫，或者如果您有Web應用程序則通過前端編寫）。您的表現腳本應反映您從用戶處看到的行爲，並進行參數化，以便它們不依賴於創建記錄的順序。

爲您自己設定一些性能目標（理想情況下，基於當前生產級別，使用乘數來覆蓋峯值）。 「100個併發用戶，沒有查詢時間超過1秒」），並使用JMeter來模擬該負載。如果你第一次到達它，恭喜 - 回家！如果沒有，請查看性能計數器以查看瓶頸位置;看看你是否可以緩解瓶頸（或調整你的查詢，你的真棒內部部署硬件可能會隱藏一些性能問題）。典型的瓶頸是CPU，RAM和磁盤I/O。

試驗不同的測試場景 - 「很多寫的」，「很多讀的」，「很多報告查詢的」，並把它們混合起來。

的想法是要了解系統上的瓶頸，看你是從這些瓶頸有多遠，並瞭解你可以做，以減輕他們什麼。一旦你知道這一點，你的決定遷移將更加強大。