MySQLと大きなページ/ hugetlbのパフォーマンスは数で向上しますか？
MySQLはInnoDBに対して大きなページ/ hugetlbをサポートしています。そして、このトピックに関する投稿はたくさんあります（ example ）。
しかし、誰かが見たパフォーマンスの変化の例を持っていますか？
他のデータベースシステムがhugetlbを使用することでパフォーマンスが向上するのを見てきました。例えば。独自のnosql分散型mmapキー値ストア。マップされたファイルが0.5GBを超えると、ストアの速度が低下します。 2GBまたは3GB後でも特に劣化はありませんでした。
観察は;の線に沿っていた。アクティブなユーザーセッションを保存した場合、たとえば100ユーザーが32MBのデータを持っていた場合、読み取り速度はXレコード/秒になります。 3000ユーザーの場合、約1GBになり、読み取り速度はX/2に低下します。読み取り速度は、ハッシュルックアップとデータのコピーの両方をカバーしていました。すべてのアクセスはマシンローカルであったため、メモリからメモリへのコピーでした。
これで、ユーザーがログアウトした場合、キー/値のスペースが32MBに縮小されたり、ハッシュテーブルが再バケット化されたりしても、ストアのデータファイルは同じままになります。ただし、読み取り速度はX/2のままで、上昇しませんでした。
TLBキャッシュミスであることが判明し、hugetlb/largeページを使用すると、ユーザーが10000に近づき、ファイルがどんどん大きくなっても、速度はX前後にとどまります。
それは素晴らしいことです。そして本能は、MySQLが同じ特性を持ち、hugetlb/largeページを有効にする必要があることを教えてくれます。しかし、いくつかの例がなければ、試してみるのは難しい販売です。
それで、誰かがパフォーマンス向上のためにhugetlb/largeページを使用しようとしましたか、そしてあなたの経験は何でしたか（良い/悪い/中立）？ DBサイズと、パフォーマンスの大まかな変化（ある場合）の両方をお聞きしたいと思います。
数を歓迎します！
MySQLの例ではありませんが、Oracleでこの正確な動作を確認しました。
http://www.pythian.com/blog/performance-tuning-hugepages-in-linux/
投稿が指摘しているように、PageTablesのサイズで/proc/meminfoを見てください。ページテーブルにRAM）の膨大な浪費が見られる場合は、それらの管理にかなりのCPU時間を費やす可能性があります。
MySQLには、それを実装する方法とその理由に関するいくつかのメモもあります。
http://dev.mysql.com/doc/refman/5.6/en/large-page-support.html
大量のメモリアクセスを実行するアプリケーションでは、トランスレーションルックアサイドバッファ（TLB）のミスが減少するため、大きなページを使用することでパフォーマンスが向上する場合があります。