CFが約1TB大きい8ノードのCassandra 2.2.5クラスタを実行しています。Cassandra圧縮には多すぎるRAMがかかります
このCFのLeveledCompactionStrategyに切り替えると、何千ものコンパクションジョブが発生しますが、それは問題ではないようです。しかし、Cassandraは絶えず増加する量のRAMを使用し始め、最終的にはカーネルによって殺される。
C *がソートされたファイルをマージするために100GのRAMを使用する理由は何でしょうか？
LCSへの最初の切り替えは、すべてのデータの大規模な再圧縮を引き起こします。あなたが結核を持っているなら、それはSSTablesとたくさんの締め固めです。 Cassandraが圧縮を行うとき、単純に比較するだけではなく、より多くの処理を必要とするので、実際にはSSTable全体で更新と削除をマージする必要があるため、「ソートされたファイルをマージする」ほど簡単ではありません。
圧縮はRAMを使用しますが、異なる設定をしていない限り、デフォルトでヒープサイズと同時圧縮の数に制限があります。 Cassandraは最高のキャッシュメモリを利用すると言いましたが、問題は発生しません。
非常に広いパーティションを使用している場合、圧縮中にCassandraはオフヒープメモリも多く使用しますが、100GBは過剰です。ヒープサイズ、圧縮処理量、およびconcurrent_compactorsを低く設定して、うまくいけばoom-killerを回避することをお勧めします。
あなたは、クラスタには負荷があなたが存在しない場合の情報http://blog.alteroot.org/articles/2015-04-20/change-cassandra-compaction-strategy-on-production-cluster.html
については、このガイドを見て、クラスタに負荷がかかっている場合は、JMXを使用して、一度にLCS一つのノード/ラックへの切り替えをする必要がありますまた、cassandra-env.shのdisable_stcs_in_l0パラメータを指定してcassandraを起動して、それが役立つかどうかを調べることもできます。これにより、L0のコンパクト化が妨げられ、すべてのデータをLCSに再コンパイルするためのコンパクションの総数が削減されます（ただし、1TBのデータでは再コンパイルに長時間かかる）。 -Dcassandra.disable_stcs_in_l0=true