如何为 mariaDB 获取更多连接或如何减少每个线程的 RAM 使用量？

Question

我们有一个 MariaDB 10.3 数据库服务器，运行在 8 核和 64GB RAM 的机器上。数据库引擎是innoDB。我们当前的max_connections = 175数据库管理员告诉我，不可能进一步增加连接数量（至少在不增加物理 RAM 等的情况下不可能）。

我们有一个高负载场景，需要将数量从 175 增加到 350。通过“调整”下面的数字可以吗？

我的直觉是，通过优化数据库设置，应该可以实现更多功能。从评论来看，我们的管理员似乎确实运行了 MySQL Tuner。在与他交谈时，我想提出一些改进建议，因此我对 SO 社区对我们设置的意见很感兴趣。

# Memory-Sizing
open-files-limit                = 16384
table_cache                     = 8192
thread_cache_size               = 32
max_allowed_packet              = 128M
myisam_sort_buffer_size         = 32M
key_buffer_size                 = 128M
tmp_table_size                  = 1G
max_heap_table_size             = 1G
query_cache_type                = 1
query_cache_size                = 16M
query_cache_limit               = 16M
sort_buffer_size                = 8M
read_buffer_size                = 1M
read_rnd_buffer_size            = 512K

# InnoDB
innodb_open_files               = 16384
innodb_strict_mode              = 1
innodb_log_file_size            = 6G
innodb_log_buffer_size          = 128M
innodb_lock_wait_timeout        = 1200
innodb_large_prefix             = 1
innodb_buffer_pool_size         = 30G
innodb_buffer_pool_instances    = 30

 # Tuning-Results
 # @see https://github.com/major/MySQLTuner-perl
 skip-name-resolve               = 1
 join_buffer_size                = 3M
 performance_schema              = ON

 # replication
 sync_binlog                     = 5
 max_binlog_size                 = 512M

我使用了两个不同的数据库内存计算器（1、2 ） ，得到了不同的结果。我还读了里克斯的《经验法则》。我认为 tmp_table_size （和堆）可能太大 - 至少有一个内存计算器表明每个连接都需要这个大小。我还按照此处的建议进行了计算，Created disk tmp tables ratio结果是0.21% - 这看起来相当低。

Tmp_disk_tables=((created_tmp_disk_tables*100/(created_tmp_tables+created_tmp_disk_tables))
= ((11597*100/(5453174 + 11597))
= 0,2122%

还有一些人建议关闭查询缓存。

（太多）变数，所以我感谢您的时间和帮助。

更新：感谢大家的评论和回答。需要明确的是：我确实信任我们的管理员 - 这不是问题 :-) 我们的设置：我们有一个负载均衡器，它将负载平均分配到当前 12 个应用程序服务器节点。每台服务器都配置有最多 14 个连接（最少 2 个）的连接池。还有一些额外的连接用于管理、维护以及能够直接连接到数据库。是的，我们已经点击了No managed connections available within configured blocking timeout- 不是在所有服务器节点上，而是在某些服务器节点上。通常此设置运行良好，但在高峰情况下会发生这种情况（并行用户/使用量较高）。所以问题实际上是如何能够增加连接数量。

现在回答你的问题：

• 如果连接主要来自 Web 服务器，则它的配置可能太高。 答案：连接来自运行 Web 应用程序的应用程序服务器
• 如果它来自应用程序，它们是否无法关闭其连接？答：根据我的分析，他们没有。在高峰情况下，我们确实有这么多并行用户使用系统
• 是否有某种形式的“连接池”？如果是这样，它有什么限制？答案：是的，我们有：每台服务器最少 2 个连接，最多 14 个连接。
• “高负载场景”答：指系统上有很多并行用户。有趣的是，我们的应用程序服务器节点上的负载（CPU 方面）相对较低，因此它们可以为更多用户提供服务，但是我们受到最大数据库连接的限制（因此我的问题是增加这些连接）
• 慢查询答案：我们确实编写了慢查询日志（记录所有>2秒的查询）并且99％的数据库查询在1秒以下完成

Answer 1

您可以在不增加 RAM 的情况下增加max_connections。但是——让我们讨论一下 175 是否实际上太大了。

如果Max_used_connections没有达到175，那么max_connections就不是真正的问题。

如果您已达到该限制，那么让我们首先调查一下客户是什么。

• 如果连接主要来自 Web 服务器，则它的配置可能太高。
• 如果它来自应用程序，它们是否无法关闭其连接？
• 是否有某种形式的“连接池”？如果是这样，它有什么限制？

关闭query_cache；它（通常）是负担多于好处。

将这些设置低于 RAM 的 1%： tmp_table_size, max_heap_table_size. 它们不仅是每个查询，而且可能是每个子查询。无论如何，1G 非常热衷于“收益递减”。基于磁盘的临时表的出现有多种原因；更改这两个设置无法删除所有磁盘临时表。

根据 的设置innodb_buffer_pool_size，我建议大量 RAM 未被使用。

我同意 0.21% 相当低。如果您想要更多类似的指标，请参阅http://mysql.rjweb.org/doc.php/mysql_analysis#tuning。它还将提供衡量查询缓存是否有用的指标。

“高负载场景”——这是什么意思？如果是“高‘Load Average’”，那就相当于“高CPU”。解决此问题的最佳方法是查找最慢和/或最常见的查询并尝试加快它们的速度。使用SlowLog可以帮助解决这个问题。