哪個 AWS RDS；目前 t3.medium 超過 CPU 基線，但不確定下一個最佳選擇是什麼

我目前有一個db.t3.medium執行 Aurora MySQL 的 RDS 實例。

由於工作量增加（預期），CPU 平均執行在其基線之上，因此在大約 10 天內將用完 CPU 積分，然後開始變得昂貴。15 分鐘的平均 CPU 使用率約為 22%（基線為 20%）。

RDS 不支持db.t3.Aurora MySQL 的任何更大版本，因此我要麼需要更改實例類，要麼遷移到 Aurora Serverless，或者同時查看第二個實例。我不確定什麼會是最好的舉動，所以很想得到一些建議。

第二審

到目前為止，我一直避免執行第二個數據庫實例，因為：

1. 我不完全了解如何正確設置它以共享工作負載（在我的應用程序中添加不同的讀取和寫入端點會很棘手）
2. 我不熟悉這是否真的會像 EC2 負載均衡器那樣共享負載
3. 我的大部分 MySQL CPU 使用來自閱讀（相對較少的寫入），所以我不預測將它分成閱讀器和編寫器來幫助太多（閱讀器可能仍然會跑得很高）。但我對這一切如何運作的理解並不完整。

我知道單個實例在可用性/故障轉移等方面存在缺陷，因此最好將其作為此次升級的獎勵來緩解。

切換實例類型

如果我切換實例類型，adb.r5.large的成本是 a 的兩倍，db.t3.medium但仍然只有 2 x vCPU。它有更多的記憶體（16 v 4），但我的問題是 CPU。

我不確定 ECU（處理能力的實際相對測量值）如何比較db.r5.large它，db.t3.medium因為它被記錄為“變數”，所以不確定我是否在比較蘋果和橘子之間r5的t3.

• db.r5.large電子控制單元 = 10
• db.t3.mediumECU = 變數

它db.r5.xlarge有 4 個 vCPU，但會使我的 RDS 成本翻兩番。

旁注：我在t3.medium保留實例上還有 9 個月的時間，所以如果我做任何事情而不是設置第二個t3實例，就會失去它。

無伺服器

根據關於無伺服器資源的相當模糊的文件*（1 ACU 具有大約 2 GB 的記憶體以及相應的 CPU 和網路，類似於 Aurora 使用者配置實例中使用的。*），我猜測 2 ACU 相當於 a db.t3.medium，所以4 個 ACU 將使我的 CPU 比我目前的設置增加一倍，而成本與db.r5.large.

無伺服器將帶來內置可用性和複製的額外好處。

RDS 負載相當穩定，而不是尖峰，因此我不會從無伺服器擴展到 1 個 ACU 的任何時候受益。

什麼是最好的？

你會怎麼做，為什麼？

謝謝！

附加資訊

• MySQL 主機伺服器上有任何 SSD 或 NVME 設備嗎？不確定 - 它只是一個標準的 AWS RDS 實例，但不確定使用了哪些預設設備。
• 顯示全球狀態；https://pastebin.com/xkTaPKKF
• 顯示全域變數；https://pastebin.com/CGjeGJCv
• 顯示完整的處理程序；https://pastebin.com/T8YveG5q
• 顯示引擎 INNODB 狀態；https://pastebin.com/EkQpyqui
• SELECT name, count FROM information_schema.innodb_metrics ORDER BY name; https://pastebin.com/kemMrNpS
• MySQl 錯誤日誌 - 過去 12 小時 - 所有這些都是在伺服器重新啟動期間生成的：https ://pastebin.com/A6sV0Qxc

狀態和變數分析：

觀察：

• 版本：5.6.10
• 4 GB 記憶體
• 正常執行時間 = 68 天 06:45:29
• 您沒有在 Windows 上執行。
• 執行 64 位版本
• 您似乎完全（或大部分）執行 InnoDB。

更重要的問題：

innodb_buffer_pool_size可以增加，但不會導致交換。（如果您沒有太多數據，那麼增加它不會有任何區別。）

如果磁碟是SSD，則增加到innodb_io_capacity500。（I/O似乎很低，所以這可能沒有任何影響。）

max_allowed_packet是 RAM 的 12%；除非您需要巨大的數據包大小，否則建議將其降低到 RAM 的 1%。

有些事情表明 I/O 很少，因為大部分工作都在 CPU 中。這進一步推動了對慢查詢的研究。

查詢記憶體 ( query_cache_type) 是ON. 並且有一些跡象表明它有大量活動。這可能是為了“修剪”而添加到 CPU 中，或者它可能有助於 CPU。（我不知道是哪個。）建議你改成DEMAND; 同時，添加SQL_CACHE到可能從 QC 和SQL_NO_CACHE其他方面受益的查詢。緊隨其後SELECT。這些更改將使 QC 更加專注，從而（希望）降低雙方的 CPU 使用率。

如果你打開慢日誌（我推薦），一定要降低long_query_time到，比如 1。

細節和其他觀察：

( Key_blocks_used * 1024 / key_buffer_size ) = 22 * 1024 / 16M = 0.13%– 使用的 key_buffer 的百分比。高水位線。– 降低 key_buffer_size（現在為 16777216）以避免不必要的記憶體使用。

( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) ) = ((16M / 0.20 + 1513M / 0.70)) / 4096M = 54.7%– 大部分可用的 ram 應可用於記憶體。– http://mysql.rjweb.org/doc.php/memory

( innodb_lru_scan_depth ) = 1,024 – “InnoDB: page_cleaner: 1000ms 預期循環佔用了……”可以通過降低 lru_scan_depth 來修復

( innodb_io_capacity_max / innodb_io_capacity ) = 2,000 / 200 = 10– 容量：max/plain – 推薦 2. Max 應該大約等於您的 I/O 子系統可以處理的 IOP。（如果驅動器類型未知，2000/200 可能是合理的一對。）

( innodb_change_buffering ) = innodb_change_buffering = none – 在 5.6.11 / 5.5.31 之前，有一個錯誤使 =“changes” 成為更安全的選項。

( innodb_doublewrite ) = innodb_doublewrite = OFF– 額外的 I/O，但在崩潰時額外的安全性。– FusionIO、Galera、Replicas、ZFS 可以關閉。

( Innodb_os_log_written ) = 512 / 5899529 = 0.31 /HR– 這是 InnoDB 繁忙程度的指標。– 非常空閒的 InnoDB。

( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 512 / (5899529 / 3600) / 2 / 48M = 3.1e-9– 比率 – (見分鐘)

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 5,899,529 / 60 * 48M / 512 = 9.67e+9– InnoDB 日誌輪換之間的分鐘數從 5.6.8 開始，可以動態更改；請務必同時更改 my.cnf。– （輪換間隔 60 分鐘的建議有些武斷。）調整 innodb_log_file_size（現在為 50331648）。（不能在 AWS 中更改。）

( Handler_rollback ) = 68,089,346 / 5899529 = 12 /sec ——為什麼有這麼多回滾？

( innodb_flush_neighbors ) = 1– 將塊寫入磁碟時的小優化。– 使用 0 表示 SSD 驅動器；1 用於硬碟。

( innodb_io_capacity ) = 200- 磁碟上每秒的 I/O 操作數。100 用於慢速驅動器；200 用於旋轉驅動器；SSD 1000-2000；乘以 RAID 係數。

( innodb_adaptive_hash_index ) = innodb_adaptive_hash_index = OFF– 通常應該是 ON。– 在某些情況下，OFF 更好。另請參見 innodb_adaptive_hash_index_parts（5.7.9 之後）和 innodb_adaptive_hash_index_partitions（MariaDB 和 Percona）。ON 涉及罕見的崩潰（錯誤 73890）。

( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF– 是否記錄所有死鎖。– 如果你被死鎖困擾，打開它。注意：如果你有很多死鎖，這可能會寫入很多磁碟。

( max_allowed_packet ) = 512M / 4096M = 12.5% – 如果您沒有要載入的大 blob（等），則減小該值。否則減小 innodb_buffer_pool_size（現在為 1586495488）以騰出空間。交換對性能來說很糟糕。

( innodb_ft_result_cache_limit ) = 2,000,000,000 / 4096M = 46.6%– FULLTEXT 結果集的字節限制。（可能沒有預先分配，但會增長？） – 降低設置。

( character_set_server ) = character_set_server = latin1 – 將 character_set_server（現在是 latin1）設置為 utf8mb4 可以幫助解決字元集問題。那是未來的預設值。

( local_infile ) = local_infile = ON – local_infile (now ON) = ON 是一個潛在的安全問題

( Qcache_lowmem_prunes ) = 142,717,868 / 5899529 = 24 /sec– QC 空間不足 – 增加 query_cache_size（現在為 88158208）

( Qcache_lowmem_prunes/Qcache_inserts ) = 142,717,868/210841277 = 67.7%– Removal Ratio（由於記憶體不足而需要修剪的頻率）

( Qcache_not_cached ) = 624,955,002 / 5899529 = 105 /sec– SQL_CACHE 已嘗試，但被忽略 – 重新考慮記憶體；調整 qcache

( Qcache_not_cached / (Qcache_hits + Com_select + Qcache_not_cached) ) = 624,955,002 / (608264262 + 835804146 + 624955002) = 30.2%– 未記憶體在 QC 中的 SELECT 百分比。– QC 不是很有用。

( (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache / query_alloc_block_size ) = (88158208 - 1227312) / 34276 / 8192 = 0.31– query_alloc_block_size vs formula – 調整 query_alloc_block_size (現在 8192)

( Select_scan ) = 171,787,477 / 5899529 = 29 /sec– 全表掃描 – 添加索引/優化查詢（除非它們是小表）

( Select_scan / Com_select ) = 171,787,477 / 835804146 = 20.6%– % 的選擇進行全表掃描。（可能被儲存常式愚弄。）——添加索引/優化查詢

( relay_log_space_limit ) = 1,000,000,000 = 953.7MB– 副本上中繼日誌的最大總大小。（0=無限）——讓我們討論一下限制的理由。

( slow_query_log ) = slow_query_log = OFF– 是否記錄慢查詢。(5.1.12)

( long_query_time ) = 10– 用於定義“慢”查詢的截止時間（秒）。– 建議 2

異常小：

( Innodb_pages_read + Innodb_pages_written ) / Uptime = 0.0118
Innodb_buffer_pool_bytes_data = 262 /sec
Innodb_buffer_pool_pages_flushed / max(Questions, Queries) = 0
Innodb_buffer_pool_pages_misc = 0
Innodb_buffer_pool_pages_misc * 16384 / innodb_buffer_pool_size = 0
Innodb_data_fsyncs = 0
Innodb_data_read = 192 /sec
Innodb_data_reads = 1.3 /HR
Innodb_data_writes = 1.3 /HR
Innodb_data_writes - Innodb_log_writes - Innodb_dblwr_writes = 1.3 /HR
Innodb_data_written = 0
Innodb_dblwr_pages_written = 0
Innodb_log_write_requests = 0
Innodb_os_log_fsyncs = 0
Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group = 0.0MB
Innodb_pages_read = 42 /HR
Innodb_pages_read + Innodb_pages_written = 42 /HR
Innodb_pages_written = 0
host_cache_size = 128

異常大：

(query_cache_size - Qcache_free_memory) / query_cache_size = 98.6%
1 - Qcache_free_memory / query_cache_size = 98.6%
Com_create_trigger = 0.00061 /HR
Com_drop_trigger = 0.00061 /HR
Com_empty_query = 0.06 /HR
Com_flush = 21 /HR
Com_purge_before_date = 12 /HR
Com_rename_user = 0.00061 /HR
Com_revoke = 0.0012 /HR
Com_show_tables = 1.6 /sec
Handler_read_last = 1.6 /sec
Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads ) = 100.0%
Qcache_total_blocks = 118,191
Qcache_total_blocks * query_cache_min_res_unit / Qcache_queries_in_cache = 14,123
Ssl_accepts = 172
Ssl_default_timeout = 7,200
Ssl_finished_accepts = 166
Ssl_session_cache_misses = 172
Ssl_verify_depth = 1.84e+19
Ssl_verify_mode = 5
back_log / max_connections = 75.6%
innodb_stats_persistent_sample_pages = 128
table_definition_cache = 5,383

異常字元串：

core_file = ON
ft_boolean_syntax = + -><()~*:\"\"&
innodb_checksums = OFF
innodb_fast_shutdown = 1
innodb_use_native_aio = OFF
log_output = TABLE
optimizer_trace = enabled=off,one_line=off
optimizer_trace_features = greedy_search=on, range_optimizer=on, dynamic_range=on, repeated_subselect=on
relay_log_recovery = ON
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN
thread_handling = multiple-connections-per-thread
time_zone = Pacific/Auckland

每秒速率 = RPS

為您的參數組中的 AWS Aurora 實例考慮的建議

read_rnd_buffer_size=131072  # from 524288 to reduce handler_read_rnd_next RPS of 98,949
read_buffer_size=512288  # from 262144 to reduce handler_read_next RPS of 1788
log_output=TABLE,FILE  # from TABLE only to have useful visible Slow and General logs
thread_cache_size=32  # from 2 - not sure how you are getting by with only 2
query_cache_type=OFF  # to eliminate CPU cycles used for QC mgmt 24 times a SECOND
query_cache_size=0  # from ~ 84M to no RAM for Query Cache

有關其他建議，請查看配置文件、聯繫資訊的網路配置文件和免費下載的實用程序腳本以幫助進行性能調整。應該調整更多的全域變數。這只是一個開始。

另一個觀察，你平均每天有 100 萬個 handler_rollback 事件的可能原因是什麼？

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