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

use*_*031 5 mysql files innodb

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/大页面来提高性能,您的体验如何(好/坏/中性)?我很想听听您看到的数据库大小和大致的性能变化(如果有的话)。

欢迎数字!

dia*_*0ne 1

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

http://www.pythian.com/blog/performance-tuning-hugepages-in-linux/

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

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

http://dev.mysql.com/doc/refman/5.6/en/large-page-support.html

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