InnoDB 负载测试

浓情chocolate
278 阅读12分钟

本文正在参加「技术专题19期 漫谈数据库技术」活动

InnoDB 负载测试

性能负载测试 InnoDB 的性能需要的不仅仅是对数据库引擎本身的简单观察。为了了解InnoDB的性能，我们需要系统运行状况和状态的完整视图。在正式负载测试期间，我们将同时收集有关 InnoDB 的指标以及来自操作系统、存储系统、CPU 和内存的指标。

在本文中，我们将用到以下技术：

  • 基于 Linux 和 Unix 的操作系统性能监控

  • 存储系统基准测试

  • 各种InnoDB刷新方法

  • 基于开源的负载测试应用程序

在使用用于负载测试的特定方法之前，我们将介绍InnoDB数据库负载测试的一般理念和用于确定进度的过程。如果没有正确理解负载测试背后的方法，我们的测试实际上是一组无用的数字，其中结果之间的相关性是不可能的。负载测试的主要目的是以可重复的方式生成指标并分析结果，通过这些方式我们可以证明或反驳有关负载下系统的假设。

负载测试允许我们查看定义的系统在定义的负载下如何运行。该负载可以采用许多不同的形式：

  • 静态或动态连接数

  • 每秒查询数

  • 动态增长的数据集大小

  • 并发执行的线程数

  • 产生和维持负载的许多其他方法

我们测试的主要目标是能够以较小的误差幅度预测系统将如何响应定义的因素，以便我们能够可靠地预测资源利用率并生成生产使用的容量计划。

负载测试还有助于防止在更改配置设置或基本操作系统变量时出现意外意外或对性能的不利影响。生产变更前的负载测试使我们能够观察、收集和分析性能指标，从而使我们能够与客户、系统用户或遵守定义的服务水平协议设定期望。

负载测试方法是针对系统和数据库工程量身定制的科学方法的扩展。

我们通过以下步骤进行操作：

1.问题。

2. 定义。

3.测试和观察。

4.分析和假设。

5. 通过测试证明/反驳。

6. 发布结果。

开源系统监视工具

在运行任何负载测试之前，我们需要能够收集系统负载指标。这些将用于测试假设并监控测试期间的活动。没有使用统计监控的测试相当于盲目操作。

用于系统资源监控的有用工具包含在 Linux 和大多数 BSD 操作系统中：

  • sar：这允许管理员收集、报告和保存系统活动信息。这可以在具有许多资源监视高级选项的间隔收集状态中使用。有许多支持工具可用于从 saroutput 生成图形。

    Sar 可以在大多数 Linux 系统上的 sysstat 包中找到。

  • top：显示当前活动的操作系统任务。如果在没有标志的情况下运行，它将仅报告活动用户拥有的任务。引用手册页将描述可用于更改显示信息的众多标志。

  • iostat：作为监视工具的 sysstat 包的一部分，这是在负载测试期间监视 I/O 资源活动的要求。如果不是

    默认情况下已安装，强烈建议您在所有负载测试期间安装和使用它。

  • free：显示当前内存使用情况，可以在简单的 bash 循环中解析。获取此信息的更有效方法是直接通过 proc 条目。

  • ps：进程监视器和快照报告。这提供了许多使用情况统计信息，包括：CPU、内存、虚拟内存、交换、pid、命令、进程所有者、线程等等。

  • /proc：此目录包含大多数可用的系统统计信息。负载测试的有用项包括但不限于以下内容：

      /proc/loadavg 0

  /proc/meminfo 。

  /proc/partitions 。

  /proc/diskstats 0

  /proc/cpuinfo 0

  /proc/swaps

  /proc/vmstat

开源 MySQL 负载测试应用程序

存在几个行业标准工具用于负载测试 MySQL，以及扩展您使用 InnoDB 引擎的任何表。我将重点介绍以下提到的开源选项：

Log Replay(日志重放)

在讨论特定应用程序之前，重要的是要了解，如果我们有一个现有的生产服务器，该服务器通过二进制日志执行和记录流量，那么我们就有可用于负载测试的数据，而不必依赖其他应用程序来生成示例测试数据。这称为日志重放，方法很简单：

  1. 使用来自 MySQL 二进制日志的记录事务。

  2. 使用 mysqlbinlog 命令将二进制日志转换为 SQL 文件。

  3. 针对有问题的数据库服务器执行 SQL 文件。

这将直接执行在生产服务器上执行的相同查询。

请务必注意，如果从生产中获取日志，则不应在生产服务器上再次执行它们，因为这可能会导致所有数量的问题。日志重播应仅用于暂存、开发或专用负载测试环境。

虽然日志重播不能替代完全负载测试，但 SQL 查询可以与以下部分中讨论的工具之一结合使用，以测试性能差异，同时使用可重复且一致的实际应用程序流量。这些 SQL 查询在特定时间/日期时段对性能问题进行故障排除时特别有用，因为我们可以重播查询并测试对配置的迭代更改，以期解决性能问题。

SysBench

SysBench 是最常引用的MySQL基准测试应用程序之一，这是有充分理由的，因为它在简单易用的命令行驱动脚本中支持大多数常规负载测试任务。默认情况下，如果您正在运行事务测试，最好的做法是在开始测试之前检查表引擎。

SysBench 本身不提供迭代、动态序列或图形输出的选项;这些功能需要通过包装器应用程序或其他方法提供。包含的测试如下：

  • CPU 密集型文件

  • I/O 测试

  • 内存测试

  • 互斥测试

  • 事务查询测试（复杂，简单）

  • 非事务性测试，只读查询测试

  • 多线程选项

  • 多节点群集聚合测试选项

Quadrant framework

Quadrant framework 是一个将SysBench，DyGraphs和Python结合到负载测试框架中的项目，以帮助创建和自动化可重复的负载测试，同时通过自动生成图形提供可视化度量分析。

提供以下功能：

  • 标准化您的 SysBench 测试，而无需编写一次性 bash 脚本来处理循环和迭代命令

  • 通过动态图绘制输出图形

  • CSV 测试结果输出，便于导入数据可视化系统或导入 SQL 数据库

  • 通过监视无限数量的 MySQL 全局状态变量来自定义您的迭代

  • 通过在迭代之间更改 MySQL 全局变量来自定义迭代

  • 在每次迭代之间运行任意 SQL 命令 在迭代之间运行任意系统命令 允许您控制迭代之间的缓存

  • 设置自定义默认值并创建配置模板，以便轻松重复和移植测试。

  • 完全用Python 2.6 OLTPbenchmark编写的可扩展代码库

OLTPbenchmark

OLTPbenchmark 是专门为OLTP数据库定制的负载测试应用程序。

它提供了可重复性和模块化测试的高效组合，具有以下功能：

  • 精确的速率控制：这允许定义并随时间更改提交请求的速率

  • 精确的交易混合控制：这允许定义和更改每种交易类型的百分比

  • 访问分布控制：这允许模拟不断变化的热点、时间倾斜等

  • 支持基于跟踪的执行：这在处理真实数据时是理想的选择

  • 可扩展设计

  • 支持统计信息收集：这负责微秒级延迟和吞吐量精度，以及操作系统资源利用率的秒精度

  • 通过 JavaScript 自动渲染：甚至可以通过许多其他可用和 gnuplot matlab 脚本促进渲染

  • SQL 方言翻译的优雅管理：这针对各种 DBMS

  • 通过标准 JDBC 接口针对所有主要的关系 DBMS 和 DBaaS 产品（在 MySQL、Postgres、Oracle、SQLServer、DB2、HSQLDB、Amazon RDS MySQL、Amazon RDS Oracle、SQL Azure 上测试） 存储过程友好架构

MySQL Benchmark Suite

MySQL Benchmark Suite是一个用于基本负载测试的工具包。如果你从源代码安装MySQL，或者下载mysq1-bench包，你可以使用几个非常基本的测试脚本。它们具有有限的功能，包括仅限于单个执行线程，并且仅当没有其他负载测试方法可用时，才应考虑这些方法。

MySQLslap

MySQLslap是常用的，但简单的脚本作为MySQL的GA发行版的客户端应用程序包含在内。它通常用于生成负载或作为大规模自定义负载测试系统中的模拟机制，其中它通过父脚本或应用程序包装以控制数据可视化和迭代控制。它具有以下选项：

  • 迭代测试前命令执行+SQL查询

  • 迭代测试后命令执行+SQL查询

  • 单连接查询限制

  • 连接并发测试 批量查询执行

  • 自动生成的查询执行

  • 索引测试控件（限制、数量等）

  • 单线程读/写控件

File System Benchmarking（文件系统基准测试）

当我们使用MySQL时，我们不可避免地以更多方式与文件系统进行交互，而不仅仅是存储数据。我们要求文件系统：

  • 尽可能快地对数据块进行操作以读取和写入日志文件
  • 存储和处理临时表，用于对无法在内存中处理的较大表进行排序
  • 在硬件故障时还提供冗余

如果我们可以在内存中运行整个数据库，那么它几乎总是可以快速响应，但是对于大于可用系统 RAM 的数据库，我们需要调整文件系统以使其性能最佳。为了调整文件系统并确保工作负载的最佳设置，我们将专注于 I/O 资源。运行文件系统基准测试时，请确保运行多个迭代，最好至少运行十次迭代，以便在删除异常值的情况下可以看到实际平均值。为此，我们可以使用以下常用工具来定义可用的 IOPS，然后测量 IOPS 利用率：

HDPARM

该工具包含在 GNU/Linux 操作系统中，报告当前的硬盘统计信息和配置。它还提供了一个接口来配置

最大化或与特定数据库配置结合使用的硬件。特别令人感兴趣的是 hdparm 命令选项：

  • --direct：这将设备设置为通过O_DIRECT刷新方法运行，这将在本章后面介绍。从手册页：

这会绕过页面缓存，导致读取直接从驱动器进入 hdparm 的缓冲区，使用所谓的“原始”I/O。

  • -g：显示驱动器几何形状。

  • -t：执行设备读取计时。

  • -T：执行缓存读取计时。

  • - i：此显示驱动器标识。

  • -I：直接从驱动器提供详细/当前信息。

  • -w：这将禁用写缓存，写缓存在基于 RAID 和 SSD 的卷上特别有用。

bonnie++

一个特定于 I/O 的基准测试工具，它将报告存储系统的性能，我们稍后可以使用它来调整 I/O 配置的 InnoDB 设置。以下是我们可以在InnoDB调优过程中引用的示例命令：

bonnie++-r 512 -s 1024 -d/tmp -f -b-n 1

命令标志定义以下内容：

  • -r：这指定了要使用的内存;可以显式设置，也可以根据机器报告的 RAM 规格设置 Bonnie++

  • -s：这有助于在每次测试之前进行同步

  • -d：这定义了在测试期间写入文件的目录

  • -f：这是一个快速模式控制;如果没有参数，则跳过每字符 IO 测试，否则指定每字符 IO 测试的测试大小（默认为 20 M）

  • -b：这指定不写缓冲;每次写入后发出 fsync （）

  • -n：这指定要运行的测试数量

Fio

这是另一个特定于 I/O 的基准测试工具，可用于基于配置文件创建批处理负载测试作业。与Bonnie++相比，此应用程序的优势可以说是更详细，更容易解释报告。

InnoDB 冲洗方法

InnoDB以不同的方式处理磁盘刷新，与文件系统接口以确保数据写入磁盘。以下选项适用，可能会以显著的方式影响写入性能。在生产使用之前，应在系统上对这些设置进行基准测试，以确保充分利用硬件功能。在某些情况下，对这些设置的简单更改可能会加倍

由于写入性能效率而能够执行的每秒查询数。

  • fdatasync（默认设置）：InnoDB 使用 fsync （） 调用将数据和日志刷新到磁盘。适用于大多数工作负载，但仍然是一个保守的选择，并且容易产生 I/O 性能损失。

  • O_DSYNC：这可以为InnoDB文件位于光纤连接的DAS或SAN设备上的SELECT密集型工作负载提供好处。

  • O_DIRECT：这有助于防止InnoDB和文件系统缓存之间的数据双重缓冲，因为文件可以通过原始I / O读取。

InnoDB刷新方法比较图表设置

image.png

线程并发测试

线程数或数据库的并发连接数应以迭代方式进行测试。

在测试此操作容量限制（将通过max_connect离子启动变量设置）时，不能在短时间内大幅改变测试值。

对于具有大量 RAM 可用于每线程缓冲区的服务器，迭代的保守值应不高于每次迭代增加 50 个连接的值，或者在具有较少可用 RAM 的服务器上，每次迭代不高于 10 个连接增加的值。

avatar
文章
阅读
粉丝