MariaDB 性能模式 (MariaDB Performance Schema)是一个强大的工具,旨在监控和分析 MariaDB 服务器的性能。它提供了对数据库内部运作的详细洞察,使数据库管理员和开发人员能够识别并优化性能瓶颈。在这篇博客文章中,我们将深入探讨 MariaDB 性能模式的复杂性、其组成部分以及如何有效利用它来进行性能调优。
了解Performance Schema
性能模式是 MariaDB 服务器中嵌入的一个功能丰富的工具,它捕获并公开了关于服务器活动的详细信息。它在低级别上运行,提供对诸如 SQL 语句执行、锁定、资源利用等事件的洞察。启用和配置性能模式对于诊断和解决 MariaDB 环境中的性能问题至关重要。与传统的存储引擎不同,性能模式作为一个单独的内存数据库运行,提供了对服务器性能各个方面的详细洞察。
性能模式的核心设计是为了回答一些与数据库性能最相关的问题:
时间花在了哪里?
性能模式记录了数据库内各种事件执行的详细信息,允许管理员精确地找出在查询执行期间时间被消耗的地方。
谁使用了最多的资源/时间?
通过分析性能模式数据,管理员可以识别出消耗最多资源或时间的用户、连接或进程,从而使他们能够优化资源分配和查询执行。
执行了什么来消耗这些资源?
性能模式捕获了关于执行的语句、查询和操作的详细信息,提供了对哪些具体行为消耗了数据库资源的洞察。
何时执行的?
使用性能模式,管理员可以分析数据库内各种事件和操作的时间安排,基于工作负载模式促进性能调优和优化。
需要考虑的要点
虽然性能模式由于其数据收集机制确实会带来一些开销,但理解这种影响通常是微小的,并且被它在性能分析和优化方面提供的益处所超过是非常重要的。这里有几个要点,在解决这些担忧时需要考虑:
-
选择性检测
性能模式允许选择性检测,意味着用户可以选择要监控的事件和活动。通过仅启用必要的检测工具,用户可以在最小化开销的同时,仍然获得有关性能指标的有价值洞察。 -
低开销
随着 MariaDB 版本的进步,与性能模式相关的开销已显著减少。现代实现旨在最小化性能影响,确保性能分析的好处超过了任何潜在的缺点。 -
动态配置
性能模式提供了动态配置选项,允许用户根据具体的监控需求调整设置。通过微调数据收集大小等参数,用户可以在性能分析和系统资源之间取得平衡。 -
隔离测试
在生产环境中启用性能模式之前,用户可以进行隔离测试以评估其对性能的影响。通过在启用性能模式前后监控系统指标,用户可以量化任何性能影响并做出明智的决策。 -
好处超过缺点
尽管开销微小,性能模式在性能分析、查询优化和故障排除方面的好处远远超过了任何潜在的缺点。通过利用性能模式,用户获得了有关数据库性能的有价值洞察,使他们能够更有效地识别和解决瓶颈。
虽然对性能模式影响性能的担忧是合理的,但认识到它提供的好处超过了任何潜在的缺点是很重要的。通过选择性地启用检测工具、微调配置设置和进行彻底测试,用户可以利用性能模式的力量来优化 MariaDB 性能,而不会造成显著的性能下降。
启动和应用Performance Schema
在深入使用之前,让我们确保性能模式在您的 MariaDB 安装中已启用。可以通过在 MariaDB 配置文件(my.cnf)中添加以下行来启用性能模式:
[mysqld]
performance_schema=ON
一旦启用了性能模式,您可以通过登录到 MariaDB 服务器并运行以下 SQL 命令来验证其状态:
SHOW VARIABLES LIKE 'performance_schema';
使用Tables
在使用 MariaDB 中的性能模式时,了解如何有效地与其表交互至关重要。这些表的特点是名称使用小写,并且标识符较长,而列名则使用大写,尽管这不会影响功能。需要注意的是,这些表驻留在内存中,没有任何索引,这意味着数据在数据库重启时会丢失。为了持久化数据,需要使用手动脚本或 SQL 命令,因为没有自动的磁盘持久化。通常,查询涉及使用 SELECT 语句检索数据,更新 setup_* 表中的选定列,或截断 events_* 和 summary 表以释放空间。
重要的是要强调,禁用性能模式并不像切换一个全局变量那么简单;相反,必须手动截断表。为了有效地利用性能模式,用户需要对 PERFORMANCE_SCHEMA.* 对象拥有 SELECT、UPDATE 和 DROP 权限。通过掌握这些实践,用户可以利用性能模式的力量进行全面的数据库性能分析和优化。
为数据收集定义适当的Sizing
在 MariaDB 性能模式中优化数据收集时,定义适当的大小参数至关重要。默认情况下,或者通过自动调整大小的机制,用户可以通过在 MariaDB 控制台执行 show global variables like ‘performance_schema%’;
来确定当前设置。然而,重要的是要理解这些设置依赖于四个关键变量:max_connections
、table_definition_cache
、table_open_cache
和 open_files_limit
。此外,它们受到操作系统级别设置的“ulimit”的影响。虽然这些性能变量可以定制,但必须谨慎行事,以避免内存过度分配。如果设置的值过高,可能会导致过度的内存使用,并且如果可用内存不足,可能会导致服务器启动失败。在确定数据收集的适当大小时,重要的是要考虑所需的历时深度,而不是基于时间间隔来定义它。大小通常由有效性能分析所需的历史事件数量决定。
通过仔细配置这些参数,用户可以在资源利用率和收集的性能数据深度之间取得平衡,确保 MariaDB 服务器性能最优,同时不会压垮系统资源。通过使用云存储来存储数据,您不仅可以节省成本,还可以获得灵活性、可扩展性和增强的数据管理能力。
性能模式的组成部分
性能模式由多个组件组成,每个组件提供有关服务器性能不同方面的特定信息。一些关键组件包括:
Events Stages:提供有关查询执行阶段的详细信息,包括查询解析、优化和执行。
Events Statements:提供有关 SQL 语句执行的详细统计信息,包括响应时间、延迟和资源消耗。
Events Wait Classes:专注于等待事件,帮助识别数据库可能遇到延迟的区域。
File I/O:监控文件 I/O 操作,揭示潜在的与磁盘相关的性能问题。
Table I/O:类似于文件 I/O,但特定于表级别操作。
Mutexes:跟踪互斥量,这是控制对共享资源访问的关键同步机制。
有效找到慢查询
SELECT * FROM performance_schema.events_statements_summary_by_digest
WHERE `SUM_TIMER_WAIT` > 1000000
ORDER BY `SUM_TIMER_WAIT` DESC;
监控资源利用率
SELECT * FROM performance_schema.events_stages_summary_global_by_event_name;
SELECT * FROM performance_schema.events_waits_summary_global_by_event_name;
分析 I/O 性能
使用文件 I/O 和表 I/O 组件来分析 I/O 操作。
识别与磁盘 I/O 相关的瓶颈,并优化查询或磁盘配置。
SELECT * FROM performance_schema.file_summary_by_instance;
SELECT * FROM performance_schema.table_io_waits_summary_by_table;
同步分析
使用互斥量组件监控互斥量,以识别潜在的竞争。
优化导致互斥量竞争的代码或查询。
SELECT * FROM performance_schema.mutex_instances;