誰かが実際に透明な巨大ページを使用して利益を得ていますか？

私は最近、透過的な巨大ページのパフォーマンスの問題に苦労しており、多くのデータベースシステムがオフにすることを推奨していることに気付きました。私はOracle、Postgresql、MySQL、Cassandra、NuoDB、Redis、Hadoopなどについて話している。

たとえば：

• Peter Zaitsev（2014-07-23）。なぜTokuDBは透明のhugepagesを嫌っています。ペルコナ。
• ミケーレ・ケイシー（2013-09-17）。透明で巨大なページのパフォーマンスの問題。オラクル。
• Adam AbrevayaおよびOleg Levin（2014-05-15）。 Linux Transparent Huge Pages、JEMalloc、NuoDB。NuoDB DevCentre。

だから私は思っています：この機能からどのような種類のワークロードが恩恵を受けるのですか？

巨大なページは、同じブロックに大量の情報を書き込む必要がある状況で役立ちます。これは、ディスク書き込みの戦略に関連する可能性があり、キャッシングにとって重要な場合があります。すべての構成オプションと同様に、ユースケースが適合しない場合は意味がありません。

したがって、答えは、同じブロックで実際に大量のデータを必要とするワークロードは、巨大なページから利益を得ることです。データが非常に大きい場合、データを収めることはできませんが、多数のページファイルに分割する必要があり、それらの数が多すぎて処理できない場合や、何らかの理由で不良になる場合があります。ファイルが望ましい-巨大なページファイルの場合があります。

実際には、その必要性に遭遇したことはありませんが、キャッシュの管理からわかっています。これは現実のものであり、どこかで、巨大なページの恩恵を受けることができます。

cassandraがhugepagesの恩恵を受けないと誰が言ったのかわかりません。/ sys / kernel / mm / transparent_hugepageからのデフラグオプションの方向で少しおしゃべりになりたいかもしれません。

hugepageの有無にかかわらずcassandraクラスターを個人的にテストしたところ、300 bから最大4kまでのさまざまなパーティションサイズでさまざまなテストを行った後、それらを再度有効にすることがわかりました。