RDS 實例上的 CPU 使用率單調增加，而查詢量沒有變化

我有兩個 RDS 實例：一個 R/W 主實例和一個只讀副本。

6 月 29 日，副本停止註冊複製數據 - 不確定這是否相關。

7 月 3 日，master 的 CPU 使用率開始單調且急劇地增加：

它現在幾乎處於臨界 100%。

據我所知，查詢量並沒有真正改變。當時唯一發生的事情是我的 Web 層中的 django-celery 守護程序搶占了整個 CPU 核心 - 強制殺死它似乎可以解決 Web 層上的問題，但似乎可能與 DB 層問題有關。

DB 大小也同時開始單調增加：

程序列表中沒有長查詢，也沒有真正的 INSERT，所以我不確定如何找出哪些表正在增長，以及 CPU 的去向。

是否有 MySQL 診斷，同時可以顯示表大小趨勢？剖析全球正在進行的查詢？配置全域 CPU 使用情況？

我已經重新啟動伺服器幾次，但無濟於事。

伺服器上顯然還有很多空間，但是當我們達到 100% 的 CPU 使用率時，事情會變得很糟糕，所以非常感謝任何幫助！

我有一些關於在這些峰值期間可以在 MySQL 中執行的表大小的問題

以 StorageEngine 為單位的數據庫大小 (MB)

SELECT IFNULL(B.engine,'Total') "Storage Engine", CONCAT(LPAD(REPLACE(FORMAT(
B.DSize/POWER(1024,pw),3),',',''),17,' '),' ',SUBSTR(' KMGTP',pw+1,1),'B') "Data Size",
CONCAT(LPAD(REPLACE(FORMAT(B.ISize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Index Size",CONCAT(LPAD(REPLACE(FORMAT(B.TSize/
POWER(1024,pw),3),',',''),17,' '),' ',SUBSTR(' KMGTP',pw+1,1),'B') "Table Size"
FROM (SELECT engine,SUM(data_length) DSize,
SUM(index_length) ISize,SUM(data_length+index_length) TSize FROM information_schema.tables
WHERE table_schema NOT IN ('mysql','information_schema','performance_schema') AND
engine IS NOT NULL GROUP BY engine WITH ROLLUP) B,(SELECT 2 pw) A ORDER BY TSize;

以數據庫 (MB) 為單位的數據庫大小

SELECT DBName,CONCAT(LPAD(FORMAT(SDSize/POWER(1024,pw),3),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Data Size",
CONCAT(LPAD(FORMAT(SXSize/POWER(1024,pw),3),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Index Size",
CONCAT(LPAD(FORMAT(STSize/POWER(1024,pw),3),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Total Size" FROM (SELECT
IFNULL(DB,'All Databases') DBName,SUM(DSize) SDSize,SUM(XSize) SXSize,
SUM(TSize) STSize FROM (SELECT table_schema DB,data_length DSize,
index_length XSize,data_length+index_length TSize FROM information_schema.tables
WHERE table_schema NOT IN ('mysql','information_schema','performance_schema')) AAA
GROUP BY DB WITH ROLLUP) AA,(SELECT 2 pw) BB ORDER BY (SDSize+SXSize);

以 Database/StorageEngine (MB) 計的數據庫大小

SELECT IF(ISNULL(B.table_schema)+ISNULL(B.engine)=2,"Storage for All Databases",
IF(ISNULL(B.table_schema)+ISNULL(B.engine)=1,CONCAT("Storage for ",B.table_schema),
CONCAT(B.engine," Tables for ",B.table_schema))) Statistic,CONCAT(LPAD(REPLACE(FORMAT(
B.DSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Data Size",CONCAT(LPAD(REPLACE(FORMAT(
B.ISize/POWER(1024,pw),3),',',''),17,' '),' ',SUBSTR(' KMGTP',pw+1,1),'B') "Index Size",
CONCAT(LPAD(REPLACE(FORMAT(B.TSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Table Size" FROM (SELECT table_schema,engine,
SUM(data_length) DSize,SUM(index_length) ISize,SUM(data_length+index_length) TSize
FROM information_schema.tables WHERE table_schema NOT IN
('mysql','information_schema','performance_schema') AND engine IS NOT NULL
GROUP BY table_schema,engine WITH ROLLUP) B,(SELECT 2 pw) A ORDER BY TSize;

注意某些標記

• Innodb_buffer_pool_pages_dirty
• Innodb_data_reads
• Innodb_data_writes

我建議下載 MySQL Administrator（我知道，它已經過時了，但我仍然使用它，以便在一天中快速而骯髒的“我現在想查看統計資訊”的時刻）並設置它。我定制了自己的圖表來觀察 InnoDB 緩衝池的大小及其臟頁。您也可以只使用 Connection Health 選項卡。

在對大量狀態輸出進行比較後，我得出的結論是查詢量沒有差異，也沒有意外/有害的查詢。

作為最後的手段，我刪除了只讀副本，master 的 binlog 大小很快減小到 0B。

當它達到 0B 時，CPU 使用率也回落到以前的水平 - ~5%。

這看起來有點像 MySQL 複製程式碼中的一個錯誤，它是由 6 月 29 日的 RDS 中斷觸發的。奴隸停止接受主人的回放，我們被困在那裡，沒有任何明顯的跡象表明這是問題所在。

建議在類似情況下仔細檢查主從複製狀態給其他任何人。

引用自：https://dba.stackexchange.com/questions/20813