我有一個 AWS RDS (MySQL 5.6.35)db.m3.medium在過去兩週內嘗試修改表的結構時給了我一個隨機錯誤：

#1041 - Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space

即使在記憶體少得多的小得多的實例上，我也從未遇到過此錯誤。應該注意的是，在此實例上啟用了加密**，**因此可能會增加一點負載。

當我在控制台中檢查記憶體統計資訊時，它似乎甚至沒有使用接近 100% 的使用率。該實例似乎也根本沒有交換。重新啟動後，我可以很好地修改表。該表非常小… < 10 列，成本很小，行數也不多（<100）。奇怪的是，我們沒有修改 RDS 中的預設緩衝區大小（實例記憶體分配的 3/4）。不僅如此，在檢查了緩衝表之後，一切似乎都還不錯。

我在這裡錯過了什麼嗎？

更新：它又發生了。重新啟動 RDS 伺服器似乎可以緩解正在發生的任何問題。這是事件發生時緩衝區統計資訊的螢幕截圖（這是在修復問題的重新啟動之前）…

2017 年 9 月 1 日更新：我認為在將 RDS 實例升級到…之後，我們暫時緩解了這個問題m4.large……並且有一段時間，確實如此。但是，在今晚早些時候執行一些遷移時……果然，錯誤 #1041 - 記憶體不足。我立即檢查了我們的 CloudWatch 報告是否有任何異常情況，我們的可用記憶體非常高，甚至沒有太大的波動。此外，重新啟動解決了該問題。我還沒有看到它再次發生，但我確信在一些交易之後的幾週內它會再次發生。**這可能是數據庫損壞的跡像還是什麼？**我們從來沒有在讀取或寫入數據庫時遇到任何問題，並且所有應用程序都可以在此伺服器上正常使用它們的數據庫。我們只是無法發起ALTER TABLE從 phpMyAdmin 內部更改…

我不相信你一個人在這裡。AWS 已將我從 5.7.11 推到 5.7.17，現在當數據庫存在任何類型的記憶體壓力時，我無法執行 Alter table 命令。

看看https://forums.aws.amazon.com/thread.jspa?threadID=251866

此時，MySQL 5.6 < 5.6.37 和 5.7 < 5.7.19 中可能存在問題。

不幸的是，AWS RDS 沒有任何 5.6 圖像 > 5.6.35 或 5.7 > 5.7.17

在使用 5.7.17 之前，我已經使用 5.7.11 一段時間沒有問題。如果您能夠轉儲/恢復您的數據庫，這可能是您的最佳選擇，否則您可以試一試更大的實例。

由於這是 db.m3.medium，我看到兩個問題，也許是三個

問題 #1：可用 RAM

由於 RDS 將 75% 的 RAM 用於innodb_buffer_pool_size，這意味著您只有 960M 用於作業系統。沒有太多的淨空。

問題 #2：數據庫連接

打開和關閉多個數據庫連接可能會導致作業系統與數據庫連接競爭可用 RAM（請參閱我的舊文章：打開和關閉數據庫連接的成本是多少？）

問題#3：數據庫中的表太多

您知道當您有許多表和列時會消耗記憶體嗎？

• Apr 22, 2014:不活動的 MySQL 數據庫會消耗記憶體嗎？
• Apr 21, 2014:添加新表——記憶體使用量增加

要問自己的問題

• 您最近添加了表格嗎？
• 增加了一個或多個表中的列數？
• 許多查詢（執行）後是否有很多打開的文件表到表SHOW OPEN TABLES;？

建議

也許只是執行將在執行任何命令FLUSH TABLES;之前關閉以前訪問過的表的所有打開文件句柄。ALTER TABLE

更新 2017-08-15 08:21 EDT

我查看了您發布事件時的緩衝區統計資訊。

• 您的 InnoDB 緩衝池 98.8023% 為空 (168454 / 170496)

• 您只有 31.59375 MB (2022 * 16384 / 1048576) 的數據

• 這是我不明白的部分

  • 您有 23824 頁要刷新
  • 這意味著您有 372.25 MB (23824 * 16384 / 1048576)
  • 這就像實際數據的 11.78 倍

當只有 32 MB 的數據時，世界上怎麼可能需要刷新 372 MB？

問題#4：壓縮（可能）

我希望你沒有使用innodb_file_format Barracuda。這需要解壓縮 InnoDB 緩衝池中的頁面。需要更大的緩衝池。我之前寫過這個：

• Mar 02, 2012: innodb_file_format 梭子魚
• Jul 22, 2013: MySQL 5.5 高 CPU 使用率

問題 5：CPU

db.m3.medium 只有 1 個 vCPU。這意味著 InnoDB、加密和作業系統都在 1 個 vCPU 上執行。哎喲！！！

問題 1 重新審視

根據您的緩衝區統計資訊，您有 2664 MB 用於 InnoDB 緩衝池

• 緩衝池應該是已安裝 RAM 的 75%
• db.m3.medium 只有 3840 MB (3.75 GB)。剩餘 RAM 為 960MB
• 您的統計數據顯示 75% 的 RAM 是 2664 MB。這意味著 100% 的 RAM 為 3552 MB。
• 因此，作業系統的剩餘 RAM 不是 960 MB，而是 888 MB

推薦

請執行以下一項或兩項操作：

• 停止使用加密
• 獲得更多 RAM（升級伺服器類）

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