MySQL 为 InnoDB 提供了大页面/hugetlb 支持。还有很多帖子 (例子) 上的主题。
但是有谁能举出他们所看到的性能变化的例子吗？
我见过其他数据库系统通过使用 hugetlb 来提高性能。例如专有的 nosql 分布式 mmapped 键值存储。当 mmapped 文件超过 0.5GB 时，存储速度会变慢。即使在 2 或 3GB 之后，它也不会下降得更多。
观察结果大致如下：如果我们存储了活跃用户会话，例如，100 个用户有 32MB 的数据，则读取速度为 X 条记录/秒。3000 个用户时，数据量约为 1GB，读取速度降为 X/2。读取速度涵盖哈希查找和数据复制。所有访问都是本地机器，因此是内存到内存的复制。
现在，如果用户注销，商店的数据文件将保持不变，即使 key/val 空间缩小到 32MB，哈希表被重新分组等。但读取速度保持在 X/2，并没有上升。
结果是 TLB 缓存未命中，使用 hugetlb/large 页面意味着即使用户数量接近 10000 并且文件越来越大，速度仍将保持在 X 左右。
太棒了。直觉告诉我，MySQL 应该具有相同的特性，并且启用 hugetlb/large 页面。但如果没有一些示例，尝试起来会很困难。
那么，是否有人尝试过使用 hugetlb/large 页面来提高性能，您的体验如何（好/坏/一般）？我很想听听数据库大小是多少，以及您看到的性能变化大致是什么（如果有的话）。
欢迎提供数字！
答案1
这不是 MySQL 示例，但我在 Oracle 中看到过这种确切的行为：
http://www.pythian.com/blog/performance-tuning-hugepages-in-linux/
正如帖子所指出的，请查看/proc/meminfoPageTables 的大小。如果您发现页表浪费了大量的 RAM，则您可能会花费大量 CPU 时间来管理它们。
MySQL 也提供了一些关于如何实现它以及为什么要这样做的说明：
http://dev.mysql.com/doc/refman/5.6/en/large-page-support.html
由于转换后备缓冲区 (TLB) 未命中次数减少，执行大量内存访问的应用程序可以通过使用大页面来提高性能。