降低MySQL性能的持久性

Question

我的網站偶爾會有相當可預測的流量突發，使吞吐量比平時增加100倍。例如，我們將在電視節目中亮相，並且我預計在節目後的小時內，我將獲得比正常情況多100倍的流量。

我的理解是MySQL（InnoDB的）通常保持在一堆不同的地方我的數據：

• RAM緩衝
• commitlog
• 二進制日誌
• 實際表
• 所有上述位置在我的數據庫從屬上

考慮到我在EC2節點上並且大部分內容通過同一個網絡管道（文件系統是網絡連接的），這太「耐用」了。加上驅動器速度很慢。這些數據價值不高，我寧願少數幾分鐘的數據丟失，而不是在人羣到達時發生中斷的可能性很高。

在這些流量突發期間，如果我能負擔得起，我希望所有I/O 只有。我希望儘可能在RAM中保留儘可能多的內存（與一小時內可能觸及的數據大小相比，我擁有相當數量的內存）。如果緩衝區變得稀缺，或者I/O通道不會過載，那麼當然，我希望事情能夠發送到提交日誌或二進制日誌以發送給從服務器。如果並且只有在I/O通道沒有超載的情況下，我纔會回寫實際的表格。

換句話說，我希望MySQL/InnoDB使用「回寫」緩存算法，而不是「寫入」緩存算法。我能說服它這麼做嗎？

如果這是不可能的，我對一般的MySQL寫入性能優化技巧感興趣。大多數文檔都是關於優化讀取性能的，但是當我收到大量用戶時，我正在爲它們創建帳戶，因此這是一個繁重的工作量。

Answer 1

很大一部分，InnoDB已經這樣做了。

當你提交的數據，它的寫入進行恢復，但修改該表空間的日誌文件（數據）只有可能在以後作爲後臺進程（「檢查點」）。

可以指定你要多少IOPS（http://en.wikipedia.org/wiki/IOPS）奉獻給在新的InnoDB版本（innodb_io_capacity），其後臺進程，並提供您設置您的innodb_log_file_size足夠大的InnoDB將只落後了一段時間，趕上備份後來。

如果InnoDB的下降太落後在後臺工作，當你達到你的日誌文件的最終它會導致性能急劇驟降，並通過回有周期。請參閱這些基準測試中的'無'行： http://www.mysqlperformanceblog.com/2009/09/15/which-adaptive-should-we-use/

Answer 2

如果您可以承受一些額外的風險，這兩個更改將大大提高您的寫入性能。

設置的innodb_flush_log_at_trx_commit = 0
設置sync_binlog = 0

此外，緩衝池大小應該是服務器內存的70-80％。增加日誌文件大小和日誌緩衝區大小也可以在一定程度上有所幫助。