主页 / dba / 问题 / 311348
Accepted
TimLer
Asked: 2022-04-27 05:33:20 +0800 CST

Mariadb Benchmarking - 每秒低事务和查询

  • 772

我们在具有 90 GB 内存和 20 个 VCPU 的 Redhat 服务器 (VM) 上有一个 MariaDB 10.3。我正在尝试优化数据库。我安装了用于基准测试的 Sysbench，经过 50 秒的测试，我得到了这个值（使用默认的 MariaDB 变量）：

#Benchmarking command:
    sysbench oltp_read_write --threads=2 --report-interval=3 --histogram 
    --time=50 --table-size=1000000 --db-driver=mysql --mysql-host=firstserver
    --mysql-db=sbtest  --mysql-user=sbtest_user --mysql-password=password run

SQL statistics:
    queries performed:
        read:                            271040
        write:                           77440
        other:                           38720
        total:                           387200
    transactions:                        19360  (387.15 per sec.)
    queries:                             387200 (7742.96 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          50.0054s
    total number of events:              19360

Latency (ms):
         min:                                    3.75
         avg:                                    5.16
         max:                                   26.99
         95th percentile:                        6.55
         sum:                                99964.49

Threads fairness:
    events (avg/stddev):           9680.0000/2.00

对于本次基准测试，innodb_buffer_pool_size 仅为 2GB。我试图优化数据库以每秒获得更多事务和查询。我改变了这个变量：

#set memory (was 2 G)
innodb_buffer_pool_size=70G 

#set log file size  (was 64MB)
innodb_log_file_size=2G

#set log buffer size (was 16MB)
innodb_log_buffer_size=128M

#set temporary in memory table size  (was 16MB)
tmp_table_size=64M
max_heap_table_size= 64M


# set query cache     (was 1MB)
query_cache_size=64M

但结果几乎没有改变。

mysql mariadb

2 个回答

  1. Best Answer

    我注意到你有 20 个 CPU 内核，但你只运行 sysbench 有 2 个线程。使用更多线程可能会获得更好的结果。通常给出的指导方针是 CPU 内核数量的 2 倍，所以至少用--threads=40.

    我还发现 sysbench 本身具有可扩展性限制（就像任何客户端应用程序一样）。为了获得最佳结果，我运行了多个客户端主机实例，所有实例都运行 sysbench 并通过网络连接到同一个数据库。

    如果您的数据仍然很小，那么将缓冲池增加 35 倍根本无济于事，我想这是为了 sysbench 运行。这就像将您的 35,000 平方英尺仓库升级为 100 万平方英尺的仓库来存储您的个人照片集。

    目前尚不清楚为什么您认为增加其他变量会有所帮助。您是否有一些指标指出这些是瓶颈？您的 innodb 提交需要等待日志缓冲区刷新多少次？您的查询中有多少百分比使用了临时表，但必须将临时表写入磁盘而不是使用内存中的临时表？

    我的观点是，随机调整选择以查看它对基准测试的影响不会引导您优化服务器。你不像科学家或工程师那样接近它。如果其中一项有所作为，您怎么知道哪一项很重要？或者您会因此在您的生产 MySQL 服务器上进行所有相同的更改吗？如果是这样，那怎么不是一种迷信的仪式，就像在肩膀上撒盐以求好运？

    • 1

  2. 为了帮助其他 DBA，我想在Bill 的回答中添加“O'Reilly High Performance mysql”一书中的一些句子：

    不该做什么

    您可能被期望（或相信您被期望）设置基准套件并通过迭代更改其配置来“调整”您的服务器以寻找最佳设置。这通常不是我们建议大多数人做的事情。它需要大量的工作和研究，而在大多数情况下，潜在的回报是如此之小，以至于浪费了大量的时间。您最好将这些时间花在其他事情上，例如检查备份、监控查询计划的更改等等。

    你不应该“按比例调整”。经典的“调整率”是您的 InnoDB 缓冲池命中率应该高于某个百分比的经验法则，如果命中率太低，您应该增加缓存大小。这是非常错误的建议。不管别人告诉你什么，缓存命中率与缓存是太大还是太小都没有关系。首先，命中率取决于工作负载——有些工作负载根本无法缓存，无论缓存有多大——其次，缓存命中毫无意义，原因我们稍后会解释。有时会发生缓存太小，命中率低的情况，增加缓存大小会提高命中率。但是，这是一种偶然的相关性，并不表示任何有关性能或缓存大小适当的信息。

    有时看似正确的相关性的问题是人们开始相信它们将永远是真实的。Oracle DBA 放弃基于比率的调优多年 105 年前，我们希望 MySQL DBA 能够效仿。2 我们更热切地希望人们不要编写“调整脚本”来编纂这些危险的做法并将它们传授给成千上万的人。这导致了我们下一个不该做什么的建议：不要使用调优脚本！您可以在互联网上找到几个非常受欢迎的。最好忽略它们。

    我们还建议您避免使用我们在过去几段中大量使用的词调整。相反，我们更倾向于配置或优化（只要那是您实际在做的事情）。调优这个词让人联想到一个不守纪律的新手，他调整服务器然后看看会发生什么。我们在上一节中建议，这种做法最好留给那些研究服务器内部的人。“调整”您的服务器可能会浪费大量时间。

    在相关主题上，在 Internet 上搜索配置建议并不总是一个好主意。您可以在博客、论坛等中找到很多不好的建议。尽管许多专家在网上贡献了他们所知道的知识，但要判断谁是合格的并不总是那么容易。当然，我们不能就在哪里可以找到真正的专家给出公正的建议。但我们可以说，可信、有信誉的 MySQL 服务提供商通常比简单的互联网搜索结果更安全，因为拥有满意客户的人可能正在做正确的事情。然而，即使是他们的建议，在没有测试和理解的情况下应用也可能很危险，因为它可能针对的情况与你的情况不同，而你并不理解。

    最后，不要相信流行的内存消耗公式——是的，这正是 MySQL 在崩溃时自己打印出来的公式。（这里不再赘述。）这个公式来自古代。这不是了解 MySQL 在最坏情况下可以使用多少内存的可靠甚至有用的方法。您也可能会在互联网上看到此公式的一些变化。这些同样存在缺陷，即使它们添加了原始公式所没有的更多因素。事实上，你不能对 MySQL 的内存消耗设置上限。它不是控制内存分配的严格监管的数据库服务器。

    • 0

相关问题