本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Aurora 我的SQL資料庫的工作負載問題
可將資料庫工作負載視為讀取和寫入。了解「正常」資料庫工作負載後,您可以調整查詢和資料庫伺服器,以滿足變更時的需求。效能可能會有許多不同的原因,所以第一步就是了解發生了什麼變化。
-
是否進行了主要或次要版本升級?
主要版本升級包括引擎程式碼的變更,特別是在最佳化程式中,這些變更可能會變更查詢執行計畫。升級資料庫版本 (尤其是主要版本) 時,請務必分析資料庫工作負載並進行相應的調整。調整可能涉及最佳化和重寫查詢,或新增和更新參數設定,具體取決於測試結果。了解造成影響的原因將使您可以開始專注於該特定領域。
如需詳細資訊,請參閱我的 8.0 中的新增功能以及 My SQL 8.0
中新增的伺服器和狀態變數以及在 My SQL 8.0 中新增、已取代或移除的選項 ,以及比較 Aurora MySQL 第 2 版和 Aurora MySQL 第 3 版。SQL -
正在處理的數據是否有所增加(行數)?
-
是否有更多的查詢同時運行?
-
是否有結構描述或資料庫變更?
-
是否存在代碼缺陷或修復?
內容
執行處理主機度
監控執行處理主機測量結果 (例如CPU、記憶體和網路活動),以協助瞭解工作負載是否發生變更。瞭解工作負載變更有兩個主要概念:
-
[使用率] — 裝置的使用情況,例如CPU或磁碟。它可以是基於時間或基於容量的。
-
以時間為基礎 — 資源在特定觀察期間內忙碌的時間量。
-
以容量為基礎 — 系統或元件可提供的輸送量,以其容量的百分比表示。
-
-
飽和度 — 資源所需工作量超過處理的程度。當以容量為基礎的使用量達到 100% 時,就無法處理額外的工作,而且必須排入佇列。
CPU用法
您可以使用以下工具來識別使用CPU情況和飽和度:
-
CloudWatch 提供
CPUUtilization
量度。如果達到 100%,則實例已飽和。但是, CloudWatch 指標的平均值超過 1 分鐘,而且缺乏粒度。如需量度的詳細 CloudWatch 資訊,請參閱Amazon Aurora 的執行個體層級指標。
-
增強型監控提供作業系統
top
命令傳回的指標。它顯示負載平均值和以下CPU狀態,具有 1 秒的粒度:-
Idle (%)
= 閒置時間 -
IRQ (%)
= 軟件中斷 -
Nice (%)
= 具有優先級的進程的好時機。 -
Steal (%)
= 服務其他租用戶所花費的時間 (虛擬化相關) -
System (%)
= 系統時間 -
User (%)
= 使用者時間 -
Wait (%)
= I/O 等待
如需增強型監控測量結果的詳細資訊,請參閱Aurora 的作業系統指標。
-
記憶體用量
如果系統處於記憶體壓力下,且資源消耗達到飽和度,您應該觀察到高度的頁面掃描、分頁、交換和 out-of-memory 錯誤。
您可以使用下列工具來識別記憶體使用量和飽和度:
CloudWatch 提供FreeableMemory
指標,該指標顯示可以通過刷新某些操作系統緩存和當前可用內存來回收多少內存。
如需量度的詳細 CloudWatch 資訊,請參閱Amazon Aurora 的執行個體層級指標。
「增強型監控」提供下列測量結果,可協助您識別記憶體使用量問題:
-
Buffers (KB)
— 寫入儲存裝置之前用於緩衝 I/O 要求的記憶體量,以 KB 為單位。 -
Cached (KB)
— 用於快取檔案系統型 I/O 的記憶體量。 -
Free (KB)
— 未分配的內存量,以千字節為單位。 -
Swap
-緩存,免費和總計。
例如,如果您發現資料庫執行個Swap
體使用記憶體,則工作負載的記憶體總量會大於您目前可用的執行個體。建議您增加資料庫執行個體的大小,或調整工作負載以減少使用記憶體。
如需增強型監控測量結果的詳細資訊,請參閱Aurora 的作業系統指標。
如需有關使用效能結構描述和結構描述判斷哪些連線和sys
元件正在使用記憶體的詳細資訊,請參閱Aurora 我的SQL資料庫的記憶體使用量問題。
網路輸送量
CloudWatch 提供以下網路總傳輸量的測量結果,所有測量結果均在 1 分鐘內的平均值:
-
NetworkReceiveThroughput
— Aurora DB 叢集中每個執行個體從用戶端接收的網路輸送量。 -
NetworkTransmitThroughput
— Aurora DB 叢集中每個執行個體傳送至用戶端的網路輸送量。 -
NetworkThroughput
— Aurora DB 叢集中每個執行個體從用戶端接收和傳輸至用戶端的網路輸送量。 -
StorageNetworkReceiveThroughput
— 資料庫叢集中每個執行個體從 Aurora 儲存子系統接收的網路輸送量。 -
StorageNetworkTransmitThroughput
— Aurora 資料庫叢集中每個執行個體傳送至 Aurora 儲存子系統的網路輸送量。 -
StorageNetworkThroughput
— Aurora 資料庫叢集中每個執行個體從 Aurora 儲存子系統接收和傳送至 Aurora 儲存子系統的網路輸送量。
如需量度的詳細 CloudWatch 資訊,請參閱Amazon Aurora 的執行個體層級指標。
增強型監控提供network
接收 (RX) 和傳輸 (TX) 圖表,最高可達 1 秒的粒度。
如需增強型監控測量結果的詳細資訊,請參閱Aurora 的作業系統指標。
資料庫指標
檢查工作負載變更的下列 CloudWatch 指標:
-
BlockedTransactions
— 資料庫中每秒封鎖的平均交易數。 -
BufferCacheHitRatio
— 緩衝區快取所服務的要求百分比。 -
CommitThroughput
— 每秒的平均提交作業數。 -
DatabaseConnections
— 從屬端網路連線至資料庫執行處理的數目。 -
Deadlocks
— 資料庫中每秒的平均死結數。 -
DMLThroughput
— 每秒的平均插入、更新和刪除次數。 -
ResultSetCacheHitRatio
— 查詢快取所服務的要求百分比。 -
RollbackSegmentHistoryListLength
— 還原記錄,用於記錄已刪除標記記錄的已提交交易。 -
RowLockTime
— 擷取 InnoDB 資料表之資料列鎖定所花費的總時間。 -
SelectThroughput
— 每秒選取查詢的平均數目。
如需量度的詳細 CloudWatch 資訊,請參閱Amazon Aurora 的執行個體層級指標。
檢查工作負載時,請考慮下列問題:
-
最近是否有資料庫執行個體類別的變更,例如將執行個體大小從 8xlarge 縮小到 4xlarge,或從 db.r5 變更為 db.r6?
-
你可以創建一個克隆並重現問題,還是只發生在一個實例上?
-
是否存在服務器資源耗盡,過高CPU或內存耗盡? 如果是,這可能意味著需要額外的硬件。
-
一個或多個查詢需要更長的時間嗎?
-
這些變更是否因為升級而造成,尤其是主要版本升級? 如果是,則比較升級前和升級後的測量結果。
-
讀取器資料庫執行個體的數量是否有變化?
-
您是否已啟用一般、稽核或二進位記錄? 如需詳細資訊,請參閱Aurora MySQL 資料庫的記錄。
-
您是否啟用、停用或變更二進位記錄檔 (binlog) 複寫的使用?
-
是否有任何長時間運行的事務持有大量的行鎖? 檢查 InnoDB 歷史記錄列表長度(HLL)以獲取長時間運行事務的指示。
如需詳細資訊,請參閱InnoDB 歷史記錄清單長度顯著增加和部落格文章為什麼我的SELECT查詢在 Amazon Aurora 我的資SQL料庫叢集上執行緩慢?
。 -
如果大量HLL是由寫入事務引起的,則表示
UNDO
日誌正在積累(不會定期清理)。在大型寫入交易中,這種積累可以快速增長。在「我」中 SQLUNDO
,儲存在SYSTEM表格空間中。表 SYSTEM
格空間不可縮小。記UNDO
錄檔可能會導致SYSTEM
表格空間成長到數 GB,甚至 TB。清除完成後,透過取得資料的邏輯備份 (傾印) 來釋放配置的空間,然後將傾印匯入新的資料庫執行個體。 -
如果大量的原因HLL是讀取交易 (長時間執行的查詢),則可能表示查詢使用了大量的暫存空間。通過重新啟動釋放臨時空間。檢查
Temp
區段中的任何變更的 Performance Insights 資料庫指標,例如created_tmp_tables
. 如需詳細資訊,請參閱利用 極光上的 Performance Insights 來監控資料庫負載。
-
-
您可以將長時間運行的事務拆分為修改較少行的較小事務嗎?
-
被阻止的交易是否有任何變化或死鎖增加? 檢查
Locks
區段中狀態變數的任何變更的 Performance Insights 資料庫指標innodb_row_lock_time
,例如innodb_row_lock_waits
、和innodb_dead_locks
。每隔 1 分鐘或 5 分鐘。 -
是否有增加的等待事件? 使用 1 分鐘或 5 分鐘的間隔來檢查 Performance Insights 等待事件和等待類型。分析前幾個等待事件,並查看它們是否與工作負載變更或資料庫爭用相關。例如,
buf_pool mutex
表示緩衝集區爭用。如需詳細資訊,請參閱使用等待事件調校 Aurora MySQL。
Aurora 我的SQL資料庫的記憶體使用量問題
雖然 CloudWatch增強型監控和 Performance Insights 可提供作業系統層級的記憶體使用量 (例如資料庫處理序使用多少記憶體) 的完整概觀,但它們不允許您劃分引擎內可能造成此記憶體使用量的連線或元件。
若要疑難排解此問題,您可以使用效能結構描述和sys
結構描述。在 Aurora My SQL 版本 3 中,啟用效能結構描述時,預設會啟用記憶體檢測。在 Aurora 我的SQL版本 2 中,預設情況下僅啟用效能結構描述記憶體使用量的記憶體檢測。如需 [效能結構描述] 中可用來追蹤記憶體使用狀況及啟用效能結構描述記憶體檢測之資料表的相關資訊,請參閱我的SQL文件中的記
雖然 [效能結構描述] 中提供詳細資訊來追蹤目前的記憶體使用狀況,但 My SQL sys 結構描述
在結sys
構描述中,下列檢視可用於透過連線、元件和查詢來追蹤記憶體使用情況。
檢視 | 描述 |
---|---|
提供主機引擎記憶體使用情況的相關資訊。這對於識別哪些應用程序服務器或客戶端主機正在消耗內存很有用。 |
|
依執行緒 ID 提供引擎記憶體使用量的相關資訊。My 中的線程 ID SQL 可以是客戶端連接或後台線程。您可以IDs通過使用系統IDs進程列表視圖或性能映射到我的SQL連接線程表。 |
|
提供使用者引擎記憶體使用情況的資訊。這對於識別哪些使用者帳戶或用戶端正在消耗記憶體非常有用。 |
|
依引擎元件提供引擎記憶體使用量的相關資訊。這對於通過引擎緩衝區或組件全局識別內存使用情況非常有用。例如,您可能會看到 InnoDB 緩衝區集區的 |
|
提供資料庫引擎中總追蹤記憶體使用量的概觀。 |
在 Aurora My 3.05 SQL 版及更新版本中,您也可以在效能結構描述句摘要資料表中,依據陳述式MAX_TOTAL_MEMORY
欄可協助您識別自上次重設統計資料或資料庫執行處理重新啟動後,查詢摘要所使用的記憶體上限。這對於識別可能會消耗大量內存的特定查詢很有用。
注意
效能結構描述和sys
結構描述會顯示伺服器目前的記憶體使用量,以及每個連線和引擎元件所耗用記憶體的上限標記。由於效能結構描述會維護在記憶體中,因此資料庫執行個體重新啟動時會重設資訊。若要維護一段時間內的歷史記錄,建議您在效能綱要之外設定此資料的擷取和儲存。
範例 1:持續高記憶體使用量
FreeableMemory
在全球範圍內 CloudWatch,我們可以看到內存使用率在 2024-03-26 02:59 大幅增加。UTC
這並沒有告訴我們整個圖片。若要判斷哪個元件使用最多記憶體,您可以登入資料庫並查看sys.memory_global_by_current_bytes
。此表格包含 My SQL 追蹤的記憶體事件清單,以及每個事件的記憶體配置資訊。每個記憶體追蹤事件都以開頭memory/%
,後面接著事件與哪些引擎元件/功能相關聯的其他資訊。
例如,用memory/performance_schema/%
於與性能模式相關的內存事件,用memory/innodb/%
於 InnoDB,等等。如需事件命名慣例的詳細資訊,請參閱 My SQL 文件中的效能結構描述儀器命名慣例
從以下查詢中,我們可以根據其找到可能的罪魁禍首current_alloc
,但我們也可以看到許多memory/performance_schema/%
事件。
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10; +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB | | memory/performance_schema/prepared_statements_instances | 252 | 488.25 MiB | 1.94 MiB | 252 | 488.25 MiB | 1.94 MiB | | memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB | | memory/performance_schema/events_errors_summary_by_thread_by_error | 1028 | 52.27 MiB | 52.06 KiB | 1028 | 52.27 MiB | 52.06 KiB | | memory/performance_schema/events_statements_summary_by_thread_by_event_name | 4 | 47.25 MiB | 11.81 MiB | 4 | 47.25 MiB | 11.81 MiB | | memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB | | memory/performance_schema/memory_summary_by_thread_by_event_name | 4 | 31.64 MiB | 7.91 MiB | 4 | 31.64 MiB | 7.91 MiB | | memory/innodb/memory | 15227 | 27.44 MiB | 1.85 KiB | 20619 | 33.33 MiB | 1.66 KiB | | memory/sql/String::value | 74411 | 21.85 MiB | 307 bytes | 76867 | 25.54 MiB | 348 bytes | | memory/sql/TABLE | 8381 | 21.03 MiB | 2.57 KiB | 8381 | 21.03 MiB | 2.57 KiB | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 10 rows in set (0.02 sec)
我們之前提到的效能結構描述儲存在記憶體中,這表示它也會在performance_schema
記憶體檢測中追蹤。
注意
如果您發現效能綱要使用大量記憶體,而且想要限制其記憶體使用量,您可以根據需求調整資料庫參數。如需詳細資訊,請參閱我SQL的文件中的效能結構描述記憶體配置模型
為了方便閱讀,您可以重新執行相同的查詢,但排除效能結構描述事件。輸出顯示以下內容:
-
主內存消費者是
memory/sql/Prepared_statement::main_mem_root
。 -
該
current_alloc
列告訴我們,我SQL的 4.91 GiB 當前分配給此事件。 -
high_alloc column
告訴我們 4.91 GiB 是自上次重置統計數據或服務器重新啟動以current_alloc
來的高水量標記。這意味著memory/sql/Prepared_statement::main_mem_root
它處於最高價值。
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name NOT LIKE 'memory/performance_schema/%' LIMIT 10; +-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB | | memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB | | memory/innodb/memory | 17096 | 31.68 MiB | 1.90 KiB | 22498 | 37.60 MiB | 1.71 KiB | | memory/sql/String::value | 122277 | 27.94 MiB | 239 bytes | 124699 | 29.47 MiB | 247 bytes | | memory/sql/TABLE | 9927 | 24.67 MiB | 2.55 KiB | 9929 | 24.68 MiB | 2.55 KiB | | memory/innodb/lock0lock | 8888 | 19.71 MiB | 2.27 KiB | 8888 | 19.71 MiB | 2.27 KiB | | memory/sql/Prepared_statement::infrastructure | 257623 | 16.24 MiB | 66 bytes | 257631 | 16.24 MiB | 66 bytes | | memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB | | memory/innodb/sync0arr | 3 | 7.03 MiB | 2.34 MiB | 3 | 7.03 MiB | 2.34 MiB | | memory/sql/THD::main_mem_root | 815 | 6.56 MiB | 8.24 KiB | 849 | 7.19 MiB | 8.67 KiB | +-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 10 rows in set (0.06 sec)
從事件的名稱,我們可以看出這個內存正在用於準備好的語句。如果您想查看哪些連接正在使用此內存,則可以檢查內存
在下列範例中,每個連線已配置大約 7 MiB,高水位標記約為 6.29 MiB ()。current_max_alloc
這是有道理的,因為這個例子使sysbench
用 80 個表和 800 個連接與準備好的語句。如果您想要在這個案例中減少記憶體使用量,您可以最佳化應用程式的預處理陳述式使用量,以減少記憶體耗用量。
mysql> SELECT * FROM sys.memory_by_thread_by_current_bytes; +-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+ | thread_id | user | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated | +-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+ | 46 | rdsadmin@localhost | 405 | 8.47 MiB | 21.42 KiB | 8.00 MiB | 155.86 MiB | | 61 | reinvent@10.0.4.4 | 1749 | 6.72 MiB | 3.93 KiB | 6.29 MiB | 14.24 MiB | | 101 | reinvent@10.0.4.4 | 1845 | 6.71 MiB | 3.72 KiB | 6.29 MiB | 14.50 MiB | | 55 | reinvent@10.0.4.4 | 1674 | 6.68 MiB | 4.09 KiB | 6.29 MiB | 14.13 MiB | | 57 | reinvent@10.0.4.4 | 1416 | 6.66 MiB | 4.82 KiB | 6.29 MiB | 13.52 MiB | | 112 | reinvent@10.0.4.4 | 1759 | 6.66 MiB | 3.88 KiB | 6.29 MiB | 14.17 MiB | | 66 | reinvent@10.0.4.4 | 1428 | 6.64 MiB | 4.76 KiB | 6.29 MiB | 13.47 MiB | | 75 | reinvent@10.0.4.4 | 1389 | 6.62 MiB | 4.88 KiB | 6.29 MiB | 13.40 MiB | | 116 | reinvent@10.0.4.4 | 1333 | 6.61 MiB | 5.08 KiB | 6.29 MiB | 13.21 MiB | | 90 | reinvent@10.0.4.4 | 1448 | 6.59 MiB | 4.66 KiB | 6.29 MiB | 13.58 MiB | | 98 | reinvent@10.0.4.4 | 1440 | 6.57 MiB | 4.67 KiB | 6.29 MiB | 13.52 MiB | | 94 | reinvent@10.0.4.4 | 1433 | 6.57 MiB | 4.69 KiB | 6.29 MiB | 13.49 MiB | | 62 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.48 MiB | | 87 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.25 MiB | | 99 | reinvent@10.0.4.4 | 1346 | 6.54 MiB | 4.98 KiB | 6.29 MiB | 13.24 MiB | | 105 | reinvent@10.0.4.4 | 1347 | 6.54 MiB | 4.97 KiB | 6.29 MiB | 13.34 MiB | | 73 | reinvent@10.0.4.4 | 1335 | 6.54 MiB | 5.02 KiB | 6.29 MiB | 13.23 MiB | | 54 | reinvent@10.0.4.4 | 1510 | 6.53 MiB | 4.43 KiB | 6.29 MiB | 13.49 MiB | . . . . . . | 812 | reinvent@10.0.4.4 | 1259 | 6.38 MiB | 5.19 KiB | 6.29 MiB | 13.05 MiB | | 214 | reinvent@10.0.4.4 | 1279 | 6.38 MiB | 5.10 KiB | 6.29 MiB | 12.90 MiB | | 325 | reinvent@10.0.4.4 | 1254 | 6.38 MiB | 5.21 KiB | 6.29 MiB | 12.99 MiB | | 705 | reinvent@10.0.4.4 | 1273 | 6.37 MiB | 5.13 KiB | 6.29 MiB | 13.03 MiB | | 530 | reinvent@10.0.4.4 | 1268 | 6.37 MiB | 5.15 KiB | 6.29 MiB | 12.92 MiB | | 307 | reinvent@10.0.4.4 | 1263 | 6.37 MiB | 5.17 KiB | 6.29 MiB | 12.87 MiB | | 738 | reinvent@10.0.4.4 | 1260 | 6.37 MiB | 5.18 KiB | 6.29 MiB | 13.00 MiB | | 819 | reinvent@10.0.4.4 | 1252 | 6.37 MiB | 5.21 KiB | 6.29 MiB | 13.01 MiB | | 31 | innodb/srv_purge_thread | 17810 | 3.14 MiB | 184 bytes | 2.40 MiB | 205.69 MiB | | 38 | rdsadmin@localhost | 599 | 1.76 MiB | 3.01 KiB | 1.00 MiB | 25.58 MiB | | 1 | sql/main | 3756 | 1.32 MiB | 367 bytes | 355.78 KiB | 6.19 MiB | | 854 | rdsadmin@localhost | 46 | 1.08 MiB | 23.98 KiB | 1.00 MiB | 5.10 MiB | | 30 | innodb/clone_gtid_thread | 1596 | 573.14 KiB | 367 bytes | 254.91 KiB | 970.69 KiB | | 40 | rdsadmin@localhost | 235 | 245.19 KiB | 1.04 KiB | 128.88 KiB | 808.64 KiB | | 853 | rdsadmin@localhost | 96 | 94.63 KiB | 1009 bytes | 29.73 KiB | 422.45 KiB | | 36 | rdsadmin@localhost | 33 | 36.29 KiB | 1.10 KiB | 16.08 KiB | 74.15 MiB | | 33 | sql/event_scheduler | 3 | 16.27 KiB | 5.42 KiB | 16.04 KiB | 16.27 KiB | | 35 | sql/compress_gtid_table | 8 | 14.20 KiB | 1.77 KiB | 8.05 KiB | 18.62 KiB | | 25 | innodb/fts_optimize_thread | 12 | 1.86 KiB | 158 bytes | 648 bytes | 1.98 KiB | | 23 | innodb/srv_master_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 24.40 KiB | | 24 | innodb/dict_stats_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 1.35 KiB | | 5 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes | | 6 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes | | 2 | sql/aws_oscar_log_level_monitor | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 4 | innodb/io_ibuf_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 7 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 8 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 9 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 10 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 11 | innodb/srv_lra_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 12 | innodb/srv_akp_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 18 | innodb/srv_lock_timeout_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 248 bytes | | 19 | innodb/srv_error_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 20 | innodb/srv_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 21 | innodb/buf_resize_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 22 | innodb/btr_search_sys_toggle_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 32 | innodb/dict_persist_metadata_table_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 34 | sql/signal_handler | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | +-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+ 831 rows in set (2.48 sec)
如前所述,這裡的線程 ID (thd_id
) 值可以參考服務器後台線程或數據庫連接。如果要將線程 ID 值映射到數據庫連接IDs,則可以使用performance_schema.threads
表或sys.processlist
視圖,其中conn_id
是連接 ID。
mysql> SELECT thd_id,conn_id,user,db,command,state,time,last_wait FROM sys.processlist WHERE user='reinvent@10.0.4.4'; +--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+ | thd_id | conn_id | user | db | command | state | time | last_wait | +--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+ | 590 | 562 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 578 | 550 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 579 | 551 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 580 | 552 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 581 | 553 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 582 | 554 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 583 | 555 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 584 | 556 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 585 | 557 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 586 | 558 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 587 | 559 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | . . . . . . | 323 | 295 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 324 | 296 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 325 | 297 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 326 | 298 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 438 | 410 | reinvent@10.0.4.4 | sysbench | Execute | System lock | 0 | wait/lock/table/sql/handler | | 280 | 252 | reinvent@10.0.4.4 | sysbench | Sleep | starting | 0 | wait/io/socket/sql/client_connection | | 98 | 70 | reinvent@10.0.4.4 | sysbench | Query | freeing items | 0 | NULL | +--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+ 804 rows in set (5.51 sec)
現在我們停止sysbench
工作負載,關閉連接並釋放內存。再次檢查事件,我們可以確認內存已釋放,但high_alloc
仍然告訴我們高水位是什麼。在識別記憶體使用量中的短峰值時,high_alloc
資料行非常有用,您可能無法立即識別使用狀況current_alloc
,這只會顯示目前配置的記憶體。
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10; +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 512823 | 4.91 GiB | 10.04 KiB | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 1 row in set (0.00 sec)
如果您想要重設high_alloc
,您可以截斷performance_schema
記憶體摘要資料表,但這會重設所有記憶體檢測。如需詳細資訊,請參閱 My SQL 文件中的效能結構描述一般資料表特性
在下面的例子中,我們可以high_alloc
看到截斷後復位。
mysql> TRUNCATE `performance_schema`.`memory_summary_global_by_event_name`; Query OK, 0 rows affected (0.00 sec) mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10; +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 17 | 253.80 KiB | 14.93 KiB | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 1 row in set (0.00 sec)
範例 2:暫態記憶體尖峰
另一個常見的事件是資料庫伺服器上的記憶體使用量短暫尖峰。這些可能是在可釋放的記憶體中定期下降,因為記憶體已經釋放sys.memory_global_by_current_bytes
,因此很難排解。current_alloc
注意
如果「效能綱要」統計資料已重設,或已重新啟動資料庫執行處理,則在sys
或 p 中將無法使用此資訊erformance_schema
。若要保留此資訊,建議您設定外部測量結果收集。
下列「增強型監控」中的os.memory.free
度量圖顯示記憶體使用量的短暫 7 秒尖峰。增強型監控功能可讓您以最短 1 秒的間隔進行監控,非常適合捕捉像這樣的暫態尖峰。
為了協助診斷此處記憶體使用的原因,我們可以high_alloc
在記sys
憶體摘要檢視和 Perfor mance Schema 陳述式摘要表格
正如預期的那樣,由於內存使用率目前不高,因此我們在sys
模式視圖下current_alloc
看不到任何主要違規者。
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10; +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB | | memory/innodb/os0event | 439372 | 60.34 MiB | 144 bytes | 439372 | 60.34 MiB | 144 bytes | | memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB | | memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB | | memory/performance_schema/events_statements_history_long | 1 | 14.34 MiB | 14.34 MiB | 1 | 14.34 MiB | 14.34 MiB | | memory/performance_schema/events_errors_summary_by_thread_by_error | 257 | 13.07 MiB | 52.06 KiB | 257 | 13.07 MiB | 52.06 KiB | | memory/performance_schema/events_statements_summary_by_thread_by_event_name | 1 | 11.81 MiB | 11.81 MiB | 1 | 11.81 MiB | 11.81 MiB | | memory/performance_schema/events_statements_summary_by_digest.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB | | memory/performance_schema/events_statements_history_long.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB | | memory/performance_schema/events_statements_history_long.sql_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 10 rows in set (0.01 sec)
擴展視圖按順序high_alloc
,我們現在可以看到,該memory/temptable/physical_ram
組件是一個非常好的候選人在這裡。在它的最高水平,它消耗了 515.00 千 MiB。
顧名思義,我的TEMP
存儲引擎的memory/temptable/physical_ram
儀器內存使用情況SQL,這是在 My SQL 8.0 中引入的。如需有關我如何SQL使用暫存資料表的詳細資訊,請參閱我的SQL文件SQL中我的內部臨時資料表使用
注意
我們在這個例子中使用的sys.x$memory_global_by_current_bytes
視圖。
mysql> SELECT event_name, format_bytes(current_alloc) AS "currently allocated", sys.format_bytes(high_alloc) AS "high-water mark" FROM sys.x$memory_global_by_current_bytes ORDER BY high_alloc DESC LIMIT 10; +-----------------------------------------------------------------------------+---------------------+-----------------+ | event_name | currently allocated | high-water mark | +-----------------------------------------------------------------------------+---------------------+-----------------+ | memory/temptable/physical_ram | 4.00 MiB | 515.00 MiB | | memory/innodb/hash0hash | 79.07 MiB | 79.07 MiB | | memory/innodb/os0event | 63.95 MiB | 63.95 MiB | | memory/performance_schema/events_statements_summary_by_digest | 40.28 MiB | 40.28 MiB | | memory/mysys/KEY_CACHE | 16.00 MiB | 16.00 MiB | | memory/performance_schema/events_statements_history_long | 14.34 MiB | 14.34 MiB | | memory/performance_schema/events_errors_summary_by_thread_by_error | 13.07 MiB | 13.07 MiB | | memory/performance_schema/events_statements_summary_by_thread_by_event_name | 11.81 MiB | 11.81 MiB | | memory/performance_schema/events_statements_summary_by_digest.digest_text | 9.77 MiB | 9.77 MiB | | memory/performance_schema/events_statements_history_long.sql_text | 9.77 MiB | 9.77 MiB | +-----------------------------------------------------------------------------+---------------------+-----------------+ 10 rows in set (0.00 sec)
在中範例 1:持續高記憶體使用量,我們檢查了每個連接的當前內存使用情況,以確定哪個連接負責使用有問題的內存。在此範例中,記憶體已經釋放,因此檢查目前連線的記憶體使用量並不有用。
為了更深入地挖掘並找到有問題的語句,用戶和主機,我們使用性能模式。「效能綱要」包含多個陳述式摘要表格,這些資料表由不同的維度 (例如事件名稱、陳述式摘要、主機、執行緒和使用者) 切割。每個視圖都可以讓您更深入地了解某些語句的運行位置以及它們在做什麼。本節著重於MAX_TOTAL_MEMORY
,但您可以在效能綱要敘述句摘要表格說明
mysql> SHOW TABLES IN performance_schema LIKE 'events_statements_summary_%'; +------------------------------------------------------------+ | Tables_in_performance_schema (events_statements_summary_%) | +------------------------------------------------------------+ | events_statements_summary_by_account_by_event_name | | events_statements_summary_by_digest | | events_statements_summary_by_host_by_event_name | | events_statements_summary_by_program | | events_statements_summary_by_thread_by_event_name | | events_statements_summary_by_user_by_event_name | | events_statements_summary_global_by_event_name | +------------------------------------------------------------+ 7 rows in set (0.00 sec)
首先,我們檢events_statements_summary_by_digest
查一下MAX_TOTAL_MEMORY
。
從這裡我們可以看到以下內容:
-
帶有摘要的查詢
20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a
似乎是這種內存使用情況的一個很好的候選人。MAX_TOTAL_MEMORY
是 537450710,它與我們在活動中看到的高水位相匹配。memory/temptable/physical_ram
sys.x$memory_global_by_current_bytes
-
它已經運行了四次(
COUNT_STAR
),首先是在二零一四年三月二十六日 04:08:34.943 256,最後一次是四三:06.998 310。
mysql> SELECT SCHEMA_NAME,DIGEST,COUNT_STAR,MAX_TOTAL_MEMORY,FIRST_SEEN,LAST_SEEN FROM performance_schema.events_statements_summary_by_digest ORDER BY MAX_TOTAL_MEMORY DESC LIMIT 5; +-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+ | SCHEMA_NAME | DIGEST | COUNT_STAR | MAX_TOTAL_MEMORY | FIRST_SEEN | LAST_SEEN | +-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+ | sysbench | 20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a | 4 | 537450710 | 2024-03-26 04:08:34.943256 | 2024-03-26 04:43:06.998310 | | NULL | f158282ea0313fefd0a4778f6e9b92fc7d1e839af59ebd8c5eea35e12732c45d | 4 | 3636413 | 2024-03-26 04:29:32.712348 | 2024-03-26 04:36:26.269329 | | NULL | 0046bc5f642c586b8a9afd6ce1ab70612dc5b1fd2408fa8677f370c1b0ca3213 | 2 | 3459965 | 2024-03-26 04:31:37.674008 | 2024-03-26 04:32:09.410718 | | NULL | 8924f01bba3c55324701716c7b50071a60b9ceaf17108c71fd064c20c4ab14db | 1 | 3290981 | 2024-03-26 04:31:49.751506 | 2024-03-26 04:31:49.751506 | | NULL | 90142bbcb50a744fcec03a1aa336b2169761597ea06d85c7f6ab03b5a4e1d841 | 1 | 3131729 | 2024-03-26 04:15:09.719557 | 2024-03-26 04:15:09.719557 | +-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+ 5 rows in set (0.00 sec)
現在我們知道了有問題的摘要,我們可以獲得更多詳細信息,例如查詢文本,運行它的用戶以及運行位置。根據返回的摘要文本,我們可以看到這是一個通用的表表達式(CTE),它創建四個臨時表並執行四個表掃描,這是非常低效的。
mysql> SELECT SCHEMA_NAME,DIGEST_TEXT,QUERY_SAMPLE_TEXT,MAX_TOTAL_MEMORY,SUM_ROWS_SENT,SUM_ROWS_EXAMINED,SUM_CREATED_TMP_TABLES,SUM_NO_INDEX_USED FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST='20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a'\G; *************************** 1. row *************************** SCHEMA_NAME: sysbench DIGEST_TEXT: WITH RECURSIVE `cte` ( `n` ) AS ( SELECT ? FROM `sbtest1` UNION ALL SELECT `id` + ? FROM `sbtest1` ) SELECT * FROM `cte` QUERY_SAMPLE_TEXT: WITH RECURSIVE cte (n) AS ( SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte MAX_TOTAL_MEMORY: 537450710 SUM_ROWS_SENT: 80000000 SUM_ROWS_EXAMINED: 80000000 SUM_CREATED_TMP_TABLES: 4 SUM_NO_INDEX_USED: 4 1 row in set (0.01 sec)
如需有關資料events_statements_summary_by_digest
表和其他「效能結構描述」陳述式摘要表格的詳細資訊,請參閱我的SQL文件中的陳述式摘要表
您也可以執行EXPLAIN
注意
EXPLAIN ANALYZE
可以提供更多的信息EXPLAIN
,但它也運行查詢,所以要小心。
-- EXPLAIN mysql> EXPLAIN WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte; +----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+ | 1 | PRIMARY | <derived2> | NULL | ALL | NULL | NULL | NULL | NULL | 19221520 | 100.00 | NULL | | 2 | DERIVED | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index | | 3 | UNION | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index | +----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+ 3 rows in set, 1 warning (0.00 sec) -- EXPLAIN format=tree mysql> EXPLAIN format=tree WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G; *************************** 1. row *************************** EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6) -> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6) -> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) -> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) 1 row in set (0.00 sec) -- EXPLAIN ANALYZE mysql> EXPLAIN ANALYZE WITH RECURSIVE cte (n) AS (SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G; *************************** 1. row *************************** EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6) (actual time=6666..9201 rows=20e+6 loops=1) -> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6) (actual time=6666..6666 rows=20e+6 loops=1) -> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0365..2006 rows=10e+6 loops=1) -> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0311..2494 rows=10e+6 loops=1) 1 row in set (10.53 sec)
但是誰跑的? 我們可以在性能模式中看到destructive_operator
用戶擁有 537450710,這再次匹配以前MAX_TOTAL_MEMORY
的結果。
注意
效能結構描述儲存在記憶體中,因此不應將其視為唯一的稽核來源。如果您需要維護執行陳述式的歷史記錄,以及使用者的使用者,建議您啟用稽核記錄。如果您還需要維護記憶體使用量的資訊,建議您將監視設定為匯出並儲存這些值。
mysql> SELECT USER,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_user_by_event_name ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5; +----------------------+---------------------------+------------+------------------+ | USER | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY | +----------------------+---------------------------+------------+------------------+ | destructive_operator | statement/sql/select | 4 | 537450710 | | rdsadmin | statement/sql/select | 4172 | 3290981 | | rdsadmin | statement/sql/show_tables | 2 | 3615821 | | rdsadmin | statement/sql/show_fields | 2 | 3459965 | | rdsadmin | statement/sql/show_status | 75 | 1914976 | +----------------------+---------------------------+------------+------------------+ 5 rows in set (0.00 sec) mysql> SELECT HOST,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_host_by_event_name WHERE HOST != 'localhost' AND COUNT_STAR>0 ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5; +------------+----------------------+------------+------------------+ | HOST | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY | +------------+----------------------+------------+------------------+ | 10.0.8.231 | statement/sql/select | 4 | 537450710 | +------------+----------------------+------------+------------------+ 1 row in set (0.00 sec)
Aurora 的 out-of-memory 疑難排解我的SQL資料庫
Aurora My SQL aurora_oom_response
執行個體層級參數可讓資料庫執行個體監視系統記憶體,並估計各種陳述式和連線所耗用的記憶體。如果系統的記憶體不足,它可以執行動作清單嘗試釋放該記憶體。它這樣做是為了避免由於 out-of-memory (OOM) 問題而重新啟動資料庫。執行個體層級參數會採用一串以逗號分隔的動作,資料庫執行個體在記憶體不足時所執行的動作。Aurora 我的SQL版本 2 和 3 支援此aurora_oom_response
參數。
下列值及它們的組合可用於aurora_oom_response
參數。空字符串意味著不採取任何操作,並有效地關閉該功能,使數據庫容易OOM重新啟動。
-
decline
— 當資料庫執行個體記憶體不足時,拒絕新查詢。 kill_connect
— 關閉耗用大量記憶體的資料庫連線,並結束目前的交易和資料定義語言 (DDL) 陳述式。Aurora 我的SQL版本 2 不支援此回應。如需詳細資訊,請參閱 My SQL 文件中的KILL陳述式
。 -
kill_query
— 以記憶體消耗的遞減順序結束查詢,直到執行個體記憶體表面超過低閾值為止。DDL陳述沒有結束。如需詳細資訊,請參閱 My SQL 文件中的KILL陳述式
。 -
print
— 僅列印耗用大量記憶體的查詢。 -
tune
– 調整內部資料表快取,以釋放部分記憶體給系統。Aurora My SQL 會減少用於快取 (例如記憶table_open_cache
體不足)table_definition_cache
的記憶體。最終,當系統記憶體不再不足時,Aurora My 會將記憶體使用量SQL設定回正常。 tune_buffer_pool
— 減少緩衝集區的大小以釋放部分記憶體,並使其可供資料庫伺服器處理連線。Aurora 我的SQL版本 3.06 及更高版本支援此回應。您必須
tune_buffer_pool
與aurora_oom_response
參數值kill_connect
中的任一kill_query
或配對。如果沒有,緩衝區集區大小調整不會發生,即使您包含tune_buffer_pool
在參數值中也是如此。
在 Aurora My SQL 版本低於 3.06 中,對於記憶體小於或等於 4 GiB 的資料庫執行個體類別,當執行個體處於記憶體壓力下時,預設動作包括print
、tune
decline
、和。kill_query
對於記憶體大於 4 GiB 的資料庫執行個體類別,參數值預設為空 (停用)。
在 Aurora 我的 3.06 SQL 版及更高版本中,對於記憶體小於或等於 4 GiB 的資料庫執行個體類別,Aurora My SQL 也會關閉最耗用記憶體的連線 ()。kill_connect
對於記憶體大於 4 GiB 的資料庫執行個體類別,預設參數值為print
。
如果您經常遇到 out-of-memory 問題,啟用時,可以使用記憶體摘要表performance_schema
用狀況。
如需與之相關的 Amazon CloudWatch 指標OOM,請參閱Amazon Aurora 的執行個體層級指標。如需相關的全域狀態變數OOM,請參閱Aurora 我的SQL全域狀態變數。