什么原因可能导致 AWS RDS 连接激增

Question

这是我第一次在 AWS 上使用 RDS，我使用 t2.medium 实例运行 MySQL Aurora 和默认配置。CPU 使用率和 DB 连接是很正常的，直到“某事”发生，这导致 DB 连接一直达到最大值（t2.medium 为 80 个连接）。

我只有一个 Web 应用程序，在 EC2 实例上运行。当数据库连接数达到最大值时，EC2 实例的 CPU 使用率绝对正常（25-30%），但所有尝试连接到数据库实例的结果都是“连接过多”。

我当时还检查了数据库实例的 CPU 利用率 - 它没有显示高负载信号。在罢工期间，CPU 利用率下降到 20% 并始终保持该比率。

我不明白的事情：数据库连接已达到最大值，但为什么数据库 CPU 利用率下降了？由于这些连接中的查询计算，它不应该也处于最大值吗？

请帮助我理解，非常感谢。

（当第二次罢工发生时，我不得不将 RDS 实例的大小调整为 r4.large；我现在仍在运行它，直到我发现问题......）

Answer 1

如果您运行show processlist;它，它将向您显示针对您的数据库运行的所有连接。运行show status like 'Conn%'可以显示有多少连接处于活动状态

您可能认为大量连接会增加 CPU，但最终这取决于这些连接试图完成什么，如果它们没有做太多事情但阻止您的主要应用程序运行它们的连接，那么正常的处理级别将当你没有运行你的正常进程时下降

令人讨厌的事情是能够运行 show processlist 命令，您需要实际连接到数据库，因为您处于最大连接时将无法连接。

一个小小的解决方法是增加您的最大连接数（如果可以的话）并在某个经常运行的地方设置一些监控（每 5 分钟就会捕获一次），当您的连接数超过 50 时，运行一个命令这会将所有活动连接转储到某处，以便您稍后查看。

Answer 2

在您的 RDS 中，首先检查所有 IOPS 指标。

RDS提供一定数量的IOPS，如果你的RDS实例有10GB的SSD，可能你的IOPS数量是100 IOPS（默认），这个值会根据实例SSD大小而增加。

如果你没有足够的 IOPS，你的 RDS 会被 IO 操作阻塞，导致你的 MySQL 中“发送数据”和高超时，但不会改变 CPU 使用率或内存，因为这是一个磁盘问题。

要修复它，请更改 MySQL 的配置，在 Dashboard 中更改它。

我在 EC2 实例上有 MySQL，对我来说成本很低。

见我的.cnf

[mysqld]


port                           = 3306
user                           = mysql
default-storage-engine         = InnoDB
socket                         = /var/lib/mysql/mysql.sock
pid-file                       = /var/lib/mysql/mysql.pid


log-error                      = /var/lib/mysql/mysql-error.log
log-queries-not-using-indexes  = 1
slow-query-log                 = 0
slow-query-log-file            = /var/lib/mysql/mysql-slow.log
log_error_verbosity            = 2


max-allowed-packet              = 6M
skip-name-resolve
sql-mode                        = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY
sysdate-is-now                  = 1



datadir                         = /var/lib/mysql


key-buffer-size                 = 128M
query_cache_size                = 128M #100M384M

tmp_table_size                  = 256M
max_heap_table_size             = 256M

innodb-buffer-pool-size         = 2G 
innodb_log_buffer_size          = 8M
innodb_log_file_size            = 1G


wait_timeout                    = 10
interactive_timeout             = 300


max-connect-errors              = 100000
max-connections                 = 200


sort_buffer_size                = 4M
read_buffer_size                = 2M
read_rnd_buffer_size            = 2M
join_buffer_size                = 2M
thread_stack                    = 4M
thread-cache-size               = 80


performance_schema              = on


query_cache_type                = 1 #0 #1
query_cache_limit               = 128M


table_open_cache                = 2680
open-files-limit                = 1024000
table-definition-cache          = 3024



# IOPS OPTIMIZATION #

innodb-flush-method            = O_DIRECT
innodb-log-files-in-group      = 2
innodb-flush-log-at-trx-commit = 2

innodb_buffer_pool_instances   = 1
innodb_stats_on_metadata       = 0

innodb_io_capacity             = 100
innodb_use_native_aio          = 1
innodb-file-per-table          = 0

explicit_defaults_for_timestamp = 1

[此配置适用于 2 vcpu 和 4GB RAM、10GB SSD 和 100IOPS] 在 AWS NLB + Auto Scaling 服务中对我来说很好。

其他优化是将 innodb 缓冲区增加到实例内存的 50%，并将 innodb_log_file_size 增加到 innodb-buffer-pool-size 值的 50%。

阅读：https : //dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-diskio.html

我希望能帮助你或其他有同样问题的用户。=)