MariaDB 10.4随机性能下降

如何解决MariaDB 10.4随机性能下降

我的服务器具有以下参数：

• 操作系统：Ubuntu 18.04.4 LTS x86_64
• 主机：X11DPi-N（T）
• 内核：4.15.0-112通用
• CPU：Intel Xeon Silver 4214（48）@ 2.201GHz
• GPU：ASPEED Technology，Inc. ASPEED图形家族
• 内存：18552MiB / 96336MiB
• SSD三星MZQLB960HAJR-00007 894.3G x 2

已安装5.5.5-10.4.12-MariaDB-1:10.4.12+maria~bionic。在此屏幕快照中显示了标准数据库负载：

因此，我每秒大约有400-500个选择（主要是从不大的具有500k记录的表中进行选择），每秒100-190个更新以及大约50-150个同时连接。

我的问题是：有时，由于没有明显的原因，服务器具有2000-3000个打开的连接/进程。根据{{​​1}}，它们是标准的SQL请求，但具有“正在发送数据”状态，并且具有400-500秒的运行时间。当然，此时服务器冻结，无法正常运行。我之所以说“没有明显的原因”，是因为目前我看不到用户数量的增加或网站上活动的增加。此外，重新启动MariaDB服务或完全重新启动服务器有助于避免这种情况，但并非总是如此：有时候，即使重新启动后，我也几乎立即获得了相同的2000-3000个冻结进程。

有人遇到过类似的数据库行为吗？我将不胜感激。

UPD：

1. 我所有的SELECTs都仅调用一个表（约50万条记录，没有SHOW FULL PROCESSLIST和/或子查询），并且大多数都具有JOIN，因此没有那么多的数据。

2. 错误日志显示了很多这样的记录：LIMIT 1

3. 2020-08-26 22:12:35 787380 [Warning] Aborted connection 787380 to db: ... (Got timeout reading communication packets)是50（默认值）

4. 慢查询日志未显示异常

5. 我的innodb_lock_wait_timeout设置：optimizer_switch

解决方法

这听起来像是查询优化器的一个经典案例，它随机地陷入脑瘫。这是一个由来已久的heisenbug。

当看到查询堆积时，请为堆积的ID之一运行SHOW EXPLAIN FOR thread_id。查看查询计划是否不合理。如果是这样，请编辑查询应用程序一侧以包含索引提示，以防止查询优化器弄错它。如果您无法更改查询，则必须摆弄optimizer_switch设置，直到您确定并删除使优化器发疯的特定选项。

,

error log中的所有内容？

如果数据库冻结，则很可能是磁盘问题：可能是磁盘已满，如果mariadb无法写任何东西，它会冻结1分钟，如果临时表填充了磁盘，磁盘可能已满，或者是alter在一张桌子上，使用复制算法做到；您是否正在监视磁盘使用情况（应该在映像中而不是在映像中）？可能是磁盘I / O全部由一个查询使用：然后所有查询仍将运行，但运行非常缓慢，是卡住还是真的很慢？可能是锁定问题？

由于查询运行了很长时间（400-500s），因此很可能不是锁：除非您进行了更改，否则锁等待超时会更短（at least it is on innodb : 50s）。

如果您知道没有运行ALTER TABLE，并且没有磁盘问题（you might want to check the inodes too），则仍然可能是锁定：SHOW ENGINE INNODB STATUS\G要检查。

您说过执行SHOW FULL PROCESSLIST只是标准的SQL请求，因此很可能没有ALTER TABLE。

如果您的查询写得不好，则临时表可能会填满磁盘，因此您需要EXPLAIN进行SHOW FULL PROCESSLIST分析时显示的查询，然后重写/优化/限制根据此类查询的结果集的大小，查找using temporary（有时也可以在磁盘上进行排序：using filesort）。 slow query log会告诉您是否有使用磁盘的查询（如果在重新启动服务器时查询没有被杀死）。

如果您没有时间优化查询，并且如果它们SELECT很大，可能会减慢整个数据库的运行速度，从而无法向用户显示信息（报告），则可以使用脚本花费很长时间杀死查询：这应该是万不得已的方法（您的脚本杀死查询的时间过长可能会编写它们，以便您以后可以对其进行分析）。

填充磁盘或使用所有I / O的临时表是唯一看到数据库冻结并在重新启动后重新启动的情况。对于数据库再次冻结的情况，可能是用户再次（又一次）执行相同的查询。

修改

可能不是您的数据库出现问题，而是您的Web应用程序：错误日志消息表明数据库正在终止某些连接。

查询正在发送数据和异常终止连接的组合对我来说并不常见。通常，如果Web应用程序没有关闭连接并且它们处于 Sleep 状态，则会发生中止的连接。您可以检查everything in this post：

• 检查网络问题（防火墙）
• 检查您的Web应用程序日志中的错误
• 检查max_allowed_packet是否足够大（如果您的SELECT返回一行，应该没问题）

如果存在休眠查询，则说明您没有正确关闭连接，然后达到了max_connection的限制，因此不会发生新的连接。尚不清楚的是：数据库速度很慢，还是什么都没有发生？ Web服务器端发生了什么事？

也可能是驱动程序（mariadb客户端）将连接和查询保留为正在发送数据状态，而未获取数据的末尾。如果它正在缓冲输出，并且在实际可以终止之前被杀死（并且它也不会关闭连接），则可能发生这种情况。它不符合 LIMIT 1 的要求，但这可以解释为什么在发送数据状态下存在异常中断的连接和SELECT查询。您的Web应用程序使用哪种语言？我可以想到php unbuffered查询，其中php进程崩溃以重新创建这种情况，但这可能是另一种特定于语言的问题。无论如何，这将是非常罕见的。

,

解决方案非常简单：研究了MariaDB文档（尤其是本文https://mariadb.com/kb/en/thread-pool-in-mariadb/）后，我在my.cnf中添加了以下内容，问题就消失了

thread_handling=pool-of-threads
thread_pool_size=48 
#48 is a number of CPUs