时间戳

首页 > 解决方案 > MariaDB 10.4 随机性能下降

mysql - MariaDB 10.4 随机性能下降

问题描述

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

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

在此处输入图像描述

所以我每秒大约有 400-500 次选择（主要来自具有 50 万条记录的不太大的表），每秒 100-190 次更新，以及大约 50-150 次同时连接。

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

有没有人遇到过类似的数据库行为？我会很感激任何想法。

升级版：

  1. 我所有的 SELECT 只调用一个表（约 50 万条记录，没有JOIN和/或子查询），而且大多数都有LIMIT 1，所以没有那么多数据。

  2. 错误日志显示了很多这样的记录：2020-08-26 22:12:35 787380 [Warning] Aborted connection 787380 to db: ... (Got timeout reading communication packets)

  3. innodb_lock_wait_timeout为 50（默认）

  4. 慢查询日志没有显示异常

  5. 我的optimizer_switch设置：index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on

标签： mysqlmariadbmariadb-10.4

解决方案

这听起来像是查询优化器随机死机的经典案例。这是一个长期存在的heisenbug。

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

推荐阅读