透明な巨大なページを実際に使用してその恩恵を受けている人はいますか？
私は最近、透過的な巨大ページのパフォーマンスの問題に苦しんでおり、多くのデータベースシステムがそれをオフにすることを推奨していることに気づきました。 Oracle、Postgresql、MySQL、Cassandra、NuoDB、Redis、Hadoopなどについて話しています。
たとえば：
- ピーター・ザイツェフ（2014-07-23）。 TokuDBがTransparent HugePages を嫌う理由。ペルコナ。
- ミケーレケーシー（2013-09-17）。 透過的な巨大ページのパフォーマンスの問題 。オラクル。
- AdamAbrevayaとOlegLevin（2014-05-15）。 Linuxの透過的な巨大ページ、JEMallocおよびNuoDB 。 NuoDBDevCentre。
だから私は疑問に思っています：この機能からどのような種類のワークロードが恩恵を受けますか？
巨大なページは、同じブロックに大量の情報を書き込む必要がある状況で役立ちます。これは、ディスク書き込みの戦略に関連する可能性があり、キャッシュにとって重要な場合があります。すべての構成オプションと同様に、ユースケースが適合しない場合は意味がありません。
つまり、同じブロックに大量のデータを実際に必要とするワークロードは、巨大なページの恩恵を受けるというのが答えです。データが大きすぎると収まりませんが、多数のページファイルに分割する必要があり、それらの数が多すぎて処理できないか、何らかの理由で不良になり、数が少ないほど大きくなります。ファイルが望ましいです-巨大なページファイルの場合があります。
実際には、私はそれの必要性に出くわしたことはありませんが、キャッシュの管理から知っています-それは本物であり、どこかで誰かが巨大なページから利益を得ることができます。
誰があなたに言ったのかわからないcassandraはhugepagesの恩恵を受けないでしょう。たぶん、/ sys/kernel/mm/transparent_hugepageからのデフラグオプションの方向で少しおしゃべりになりたいでしょう。
個人的には、hugepageの有無にかかわらずcassandraクラスターをテストし、300 bから4kまでのさまざまなパーティションサイズでさまざまなテストを行った後、それらを再度有効にすることができます。