MySQL服務器非常高負載

我運行〜500實時遊客，〜50K每天遊客和〜1,3million總用戶網站。我在AWS上託管我的服務器，我使用了幾種不同類型的實例。當我啓動網站時，不同的實例花費相同。當網站開始獲取用戶時，RDS實例（MySQL DB）的CPU始終保持在屋頂上，我不得不多次升級它，現在它已經開始佔據性能的主要部分和每月成本（約95％（2,8k $ /月））。我目前使用的是具有16vCPU和64GiB RAM的數據庫服務器，我還使用多可用區域部署來防止故障。 我想知道數據庫的價格是否太高是正常的，還是我做了一些非常錯誤的事情？MySQL服務器非常高負載

數據庫信息

目前我的數據庫有他們中的大多數40個表有10萬行，有些人〜2millions和1個有3000萬。我有一個系統的檔案行大於21天，當他們不再需要了。

網站信息

網站主要使用PHP，但也有一些和的NodeJS蟒蛇。

大部分網站的功能是這樣的：

開始交易
插入行
獲得最後插入的ID（lastrowid）
做一些計算
更新插入排
更新用戶
提交tran saction

我也從數據庫中以10-30秒的間隔運行100bots輪詢，他們也插入/更新數據庫有時。

額外

我做了幾件事情要儘量降低數據庫的負載。如啓用數據庫緩存，對某些查詢使用redis緩存，嘗試刪除非常慢的查詢，嘗試將存儲類型升級到「Provisioned IOPS SSD」。但似乎沒有任何幫助。

這是改變我所做的設置paramters：

我雖然有關創建幾個較小的情況下的一個MySQL集羣，但我不知道這是否會幫助，並我也不知道這是否適用於交易。

如果您需要更多信息，請詢問，對此問題的任何幫助都非常感謝！

來源

2016-07-10 Ranama

您說過您嘗試升級到預配置IOPS，但您是否已經將可用IOPS最大化？你是否仍在充分利用可用的IOPS？您需要查看「每秒讀取操作」和「每秒寫入操作」，看看它們是否受可用IOPS的限制。 –

此外，我會建議測試Aurora以查看它是否對您更好。 –

根據我的經驗，只要您提出「我怎樣才能放大表現？」這個問題，你知道你已經超出了RDS（編輯：我承認我的經驗使我對這個觀點可能已經過時）。

這聽起來像你的查詢負載是相當寫重。大量的插入和更新。如果您可以使用您的RDS版本，則應該增加innodb_log_file_size。否則，您可能不得不放棄RDS並轉移到EC2實例，您可以更輕鬆地調整MySQL。

我也會禁用MySQL查詢緩存。在每次插入/更新時，MySQL都必須掃描查詢緩存以查看是否存在需要清除的緩存結果。如果你有一個寫入繁重的工作量，這是浪費時間。將查詢緩存增加到2.56GB使其更糟！將高速緩存大小設置爲0並將高速緩存類型設置爲0.

我不知道您運行的是哪些查詢，或者您對它們進行了優化的方式。 MySQL的優化器是有限的，所以通常情況下你可以從重新設計SQL查詢中獲得巨大的好處。也就是說，改變查詢語法，以及添加正確的索引。

你應該做一個查詢審計，以找出哪些查詢是你的高負載帳戶。一個很好的免費工具是https://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html，它可以根據你的慢查詢日誌給你一個報告。使用http://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html CLI命令下載RDS慢查詢日誌。

設置您的long_query_time = 0，讓它運行一段時間來收集信息，然後將long_query_time更改回您通常使用的值。收集此日誌中的所有查詢非常重要，因爲您可能會發現75％的負載來自2秒內的查詢，但它們頻繁運行，這是服務器的負擔。

你知道哪些查詢佔負載之後，您可以就如何解決這些問題有知情策略：在應用

查詢優化或重新設計
更多緩存
橫向擴展更多的例子

來源

2016-07-10 15:43:08

我很好奇爲什麼你認爲他們有「超出RDS」。您似乎可以在仍使用RDS的情況下完成所有調整。 –

我的意見可能已過時。多年來，RDS無法調整InnoDB日誌文件大小，或者提供除基於表格的日誌之外的查詢日誌。這似乎已經改變了。但我想我對我無法登錄的數據庫服務器有偏見！ :-) –

我想答案是「你做錯了什麼」。儘管您可能在某些部分達到了限制，但您很難達到RDS限制。

從啓用詳細監控開始。這會給你一些操作系統級別的信息，這應該有助於確定你的限制因素究竟是什麼。看看你的慢查詢日誌和數據庫統計信息 - 你可能有一些查詢導致問題。

一旦你明白了這個問題 - 可能是錯誤的查詢，I/O限制或其他問題 - 那麼你可以解決它們。 RDS允許您創建多個只讀副本，因此您可以將一些讀取負載移至從機。

你也可以移動到極光，這應該會給你更好的I/O性能。或者使用PIOPS（或分配更多的磁盤，這應該會提高性能）。您正在使用SSD存儲，對不對？

另一個建議 - 如果您的計算（上述第4步）需要大量時間，您可能需要考慮將其分成兩個或更多個事務。

來源

2016-07-10 20:06:20 chris

A query_cache_size超過50M是壞消息。你經常寫 - 每桌每秒多次？這意味着QC需要多次/秒掃描以清除已更改表格的條目。當QC爲2.5GB時，這對系統是一個很大的負擔！

query_cache_type應該是DEMAND如果你可以證明它是有根據的。在這種情況下，用SQL_CACHE和SQL_NO_CACHE胡椒SELECTs。

由於您打開了緩慢日誌，因此請使用pt-query-digest查看輸出。第一個問題是什麼？

由於您的典型操作涉及到寫入，我沒有看到使用只讀Slave的優勢。

機器人是否隨機運行？或者他們都在同一時間開始？（後者可能導致CPU中的可怕尖峯等）

你如何「歸檔」「舊」記錄？最好使用PARTITIONing和「可移動表空間」。使用PARTITION BY RANGE和21個分區（加上一些額外功能）。

您的典型事務似乎與一行一起工作。它可以修改爲一次處理10個或100個？（超過100個可能不符合成本效益。）與一行中的大量查詢相比，SQL在一次執行大量行時效率更高。向我們展示SQL;我們可以深入細節。

在一個事務中插入一個新行然後更新它似乎很奇怪。在插入之前不能完全計算它嗎？長時間掛在inserted_id上可能會干擾其他人做同樣的事情。 innodb_autoinc_lock_mode的價值是多少？

做「用戶」互相交互？如果真是這樣，那麼是以哪種方式？

來源

2016-07-10 22:39:53

MySQL服務器非常高負載

回答

相關問題