在运行Debian Wheezy amd64的本地机器（i7 9200）上，我可以通过以下方式获得一些“大数据”/ HPCtypes的重要加速：
HUGETLB_MORECORE=yes将其mallocredirect到2M页。 在EC2上的Debian Wheezy（我正在使用最新的wheezy AMI ）和正常的4k页面（在c3.2xlarge，c3.4xlarge和c3.8xlarge实例上尝试过的一些可伸缩性testing）上运行得也相当不错。 但是我很好奇，看看在EC2上使用大页面是否有类似的好处，如果可能的话。
我激发了一个c3.3xlarge的实例， 像往常一样设置了大量的页面。 之后/ proc / meminfo确实报告
HugePages_Total: 4096 HugePages_Free: 4095
然而在编译libhugetlbfs之后， make func自检会触发一些内核错误。 不久之后，系统似乎locking了，但在我没有时间检查dmesg之前，看到一堆带有各种xen_和hugetlb_fault符号的调用堆栈。 一旦无响应，系统需要从AWS控制台强行停止以使其停止。
我试着重新启动，然后用HUGETLB_MORECORE=yes运行我的应用程序（如果make functesting正在打破我实际上并不需要的东西），但是同样的事情再次发生了。
任何EC2上的libhugetlbfs成功的故事 （最好用Debian）或食谱获得正确的工作 ？
研究 ：关于EC2（或Xen）上巨大页面的Googleable信息很less。 我确实发现了这一点 ，这似乎报告了同样的问题：/ proc / meminfo报告巨大页面可用，但试图使用它们内核恐慌。 文章早于新的C3实例，但build议cc2.8xlarge可能值得一试，因为它使用HVM而不是PVM。
更新 ：找不到一个最新的Debian AMI for HVM，但在cc2.8xlarge和libhugetlbfs上尝试了一个Ubuntu（13.04“raring”），而HUGETLB_MORECORE=yes似乎在这方面工作得很好。 唯一的是，它实际上减慢了我的应用程序的一点点！