AWS Aurora 可用内存不足并崩溃

Question

我们的 AWS Aurora MySQL 实例出现可用内存不足并因此崩溃的问题。AWS的回应是升级到更大的实例，但我认为这不一定能解决问题。

我们使用的是 db.r5.large 实例，内存为 15GB。

重新启动后，RAM 会下降到 5GB，这几乎是预料之中的，但随后在一周内逐渐下降到 0GB RAM，然后重新启动 - 有时会失败，需要手动重新启动实例。

CPU 使用率通常徘徊在 15% 左右，当我们进行深夜处理时，该值会达到峰值。

来自mysql innodb_buffer_pool_size 应该有多大？

SELECT CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) RIBPS FROM
(SELECT SUM(data_length+index_length) Total_InnoDB_Bytes
FROM information_schema.tables WHERE engine='InnoDB') A;

根据需要提供 10GB 来保存内存中的所有数据和索引。

SELECT (PagesData*PageSize)/POWER(1024,3) DataGB FROM
(SELECT variable_value PagesData
FROM information_schema.global_status
WHERE variable_name='Innodb_buffer_pool_pages_data') A,
(SELECT variable_value PageSize
FROM information_schema.global_status
WHERE variable_name='Innodb_page_size') B;

InnoDB 缓冲池中提供 4.6GB

SHOW FULL PROCESSLIST

仅显示几个进程，没有挂起的线程。

我的问题是，有没有一种方法可以确保可释放内存永远不会超过某个点并被释放回来以供使用，例如它永远不会低于 2GB，因此如果内存占用很大，它不会耗尽内存。

我知道这可能会影响性能，但在我扩展到更大的实例（成本加倍）并经历同样​​缓慢下降到 0 之前，我想看看它的性能如何，因为它比生产更好机器随机崩溃。

---

附加信息：

我已将各种 MySQL 输出添加到https://pastebin.com/CkRxqL04

不太确定如何在 RDS 实例上运行 Unix 命令，因为无法访问文件系统。

我检查了其他日志，似乎 CPU 也在稳步攀升，而它应该爆发并回落到正常水平。

这不是一个高流量的网站，尽管它确实在幕后做了一些繁重的工作。

在进行进一步挖掘时，我注意到有人尝试同步到从初始迁移完成后仍然处于活动状态的从站。即使作为root我也无法删除它，但这会占用内存/CPU吗？

2019-08-29 00:30:04 7112 [Note] Error reading relay log event: slave SQL thread was killed
2019-08-29 00:30:04 7112 [Note] Slave I/O thread killed while connecting to master
2019-08-29 00:30:04 7112 [Note] Slave I/O thread exiting, read up to log 'mysql-bin-changelog.000016', position 904410367

更新 19/09/09

模式似乎仍然是一样的——CPU 不断上升——尽管是逐渐的。

慢速日志是空的（我知道它已打开，因为其中之前有条目）。

我还安装了一个 APM 工具，没有出现任何可疑的情况 - 所有脚本都按照 Db 查询的时间执行。我们有一些长时间运行的 CRON 作业（3 分钟），但它们不应该影响数据库，因为它们位于网络服务器上。

Answer 1

每秒速率=RPS - 为您的 AWS Aurora 参数组考虑的建议

log_output=TABLE,FILE  # from TABLE so you can review your Error Log FILE after crash
log_warnings=2  # from 1 to include aborted_connects and other info in your Error Log
query_cache_min_res_unit=512  # from 4096 to conserve QC RAM used
query_cache_size=64M  # from ~ 443M to reduce CPU cycles used for QC management
innodb_lru_scan_depth=100  # from 1024 to conserve 90% CPU cycles used for function
thread_cache_size=24  # from 11 to reduce threads_created count
read_rnd_buffer_size=256K  # from 512K to reduce Handler_read_rnd_next RPS of 2,558
read_buffer_size=512K  # from 256K to reduce Handler_read_next RPS of 29,608
tmp_table_size=64M  # from 16M to expand capacity
max_heap_table_size=64M  # from 16M to reduce created_tmp_disk_tables RPHr of 1,134

如果允许的话，

innodb_io_capacity=1900  # from 200 to enable higher IOPS to SSD devices

观察，当 innodb_buffer_pool_reads > 50 RPS（今天小于 1 RPS）时要考虑 innodb_buffer_pool_size 调整 innodb_change_buffering=none 需要重新考虑，查看 refman 详细信息

这些建议可能有助于稳定您的实例。

免责声明：我是我的个人资料、网络个人资料中提到的网站的内容作者，我们在其中提供免费的可下载实用程序脚本来帮助提高性能、更多建议和联系信息。