MySQL 和大页面/hugetlb 性能在数量上有所提升？

Question

MySQL 对 InnoDB 有大页面/hugetlb 支持。并且有很多关于该主题的帖子（示例）。

但是有没有人有他们看到的性能变化的例子？

我已经看到其他数据库系统通过使用 Hugetlb 获得了性能。例如。专有的 nosql 分布式 mmapped 键值存储。随着 mmapped 文件增长到 0.5GB 以上，存储会变慢。即使在 2GB 或 3GB 之后，它也没有特别降级。

观察结果是：如果我们存储了活动用户会话，例如。100 个用户我们有 32MB 的数据，读取速度将是 X 条记录/秒。在 3000 个用户时，我们大约为 1GB，读取速度下降到 X/2。读取速度涵盖哈希查找和复制数据。所有访问都是机器本地的，所以它是内存到内存的复制。

现在，如果用户注销，存储的数据文件将保持不变，即使键/值空间会缩小到 32MB，哈希表被重新存储等。但读取速度保持在 X/2，并没有上升。

结果是TLB缓存未命中，使用hugetlb/大页面意味着即使用户爬到10000并且文件越来越大，速度仍将保持在X左右。

那太好了。现在本能告诉我 MySQL 应该具有相同的特性，并且可以启用 Hugetlb/大页面但是没有一些示例，很难尝试。

那么，有没有人尝试使用 Hugetlb/大页面来提高性能，您的体验如何（好/坏/中性）？我很想听听您看到的数据库大小和大致的性能变化（如果有的话）。

欢迎数字！

Answer 1

不是 MySQL 示例，但我在 Oracle 中看到过这种确切的行为：

正如该帖子所指出的，查看/proc/meminfo页表的大小。如果您发现页表的 RAM 被大量浪费，您可能会花费大量的 CPU 时间来管理它们。

MySQL 还提供了一些关于如何实现它以及为什么要实现它的注释：

由于减少了转换后备缓冲区 (TLB) 未命中，执行大量内存访问的应用程序可以通过使用大页面来获得性能改进。