私は最近、透明なhugepagesのパフォーマンスの問題に苦しんでおり、多くのデータベースシステムがそれをオフにすることをお勧めします。私はOracle、Postgresql、MySQL、Cassandra、NuoDB、Redis、Hadoopなどについて話しています。
いくつかの例:
- ピーター・ジャイツェフ(2014-07-23)。TokuDBが透明な巨大ページを嫌う理由。ペルコナ。
- ミシェル・ケーシー(2013-09-17)。透明な大容量ページのパフォーマンスの問題。信託。
- アダム・アブレバヤ(Adam Abrevaya)とオレク・レビン(2014-05-15)。 Linuxの透明な巨大ページ、JEMAlloc、NuoDB。 NuoDB開発センター。
もしそうなら、どのタイプのワークロードがこの機能の利点を享受できるのか疑問に思います。
答え1
Hugepagesは、同じブロックに大量の情報を書き込む必要がある場合に便利です。これはディスク書き込み戦略に関連する可能性があり、キャッシュに非常に重要です。すべての設定オプションと同様に、ユースケースに合わないと意味がありません。
したがって、同じブロックに実際に大量のデータを必要とするワークロードには大きなページが役立ちます。データが大きすぎる場合は、適切ではなく複数のページファイルに分割する必要があり、そのページファイルの数が多すぎるため、何らかの理由で処理するのが難しくない場合があります。 - あなたのケースには大容量ページファイルが必要です。
実際に必要な状況を見たことはありませんが、キャッシュ管理を通じて知っています。これは現実であり、どこかで誰かが巨大なページの利点を享受できるということです。
答え2
カッサンドラが大きなページでは利益を得られないと誰が言ったのかわかりません。おそらく、/sys/kernel/mm/transparent_hugepageの最適化オプションについてさらに話したいかもしれません。
私は個人的に巨大なページの有無にかかわらずCassandraクラスタをテストし、さまざまなパーティションサイズ(300bから4kまで)を使用してさまざまなテストを終えた後、それを再度有効にすることがわかります。