保留中の圧縮の急激な増加についてRCを調べる方法

現在データをロードしているcassandra 2.0.17クラスタを取得しました。突然、クラスタは圧縮タスクに対応しているようです。これは、各ノードがファームウェアの更新のために一時的にオフラインになったときと衝突するように見えます。保留中の圧縮の急激な増加についてRCを調べる方法

は、私たちのOpsCenter Dashboard

はRCを掘るする方法を疑問に思う参照してください、ヒントは大歓迎します！

また、割り当てファイルシステム間でのディスク[-io]使用のバランスをより良くする方法についても不思議です。

-rw-r--r--. 1 cass cassandra  43726347 May 5 14:17 KeyspaceBlobStore-CF_Message_1-tmp-jb-22142-CompressionInfo.db 
-rw-r--r--. 1 cass cassandra 340293724737 May 5 14:17 KeyspaceBlobStore-CF_Message_1-tmp-jb-22142-Data.db 
-rw-r--r--. 1 cass cassandra 266403840 May 5 14:17 KeyspaceBlobStore-CF_Message_1-tmp-jb-22142-Index.db

が、これはXFSのFSに効果的であるか、これは、より良い、より小さなファイルの可能なスピード違反圧縮に広げることができます：圧縮中

いくつかのCFSがこれらのような大規模な一時ファイルを作成しているようですか？

例：過去7日間の1ノードのFS使用量のサンプルは、hereがFSのblob-3の使用が主に上記の大きな一時ファイルのために大幅に増加していることを示しています。これはちょうど圧縮が長すぎるために取られたのでしょうか？

TIA

出典

2016-05-05 Steffen Winther Sørensen

あなたはコンパクションに背後取得の圧縮死のスパイラルにおそらくいるように見えます - 上>より多くのI/O + CPUは、読み込み - >コンパクションにさらに背後になって。ノードをオフラインにすると（オンラインになったときに追いつくために書き込みレベルが高くなっていることを意味する）、スパイラルが発生した可能性があります。

コンパクションでは、複数の小さなファイルを1つの大きなファイルにするために大きな一時ファイルがあることが予想されます。

これは、クラスタにノードを追加すると、クラスタに参加している間にクラスタ全体の負荷が増加する可能性があります。私たちのために時々働くアプローチの1つは、ノードをオフラインにして（nodetool disablegossip disablethriftとdisablebinaryを使用して）、読み書きを行わずにコンパクションに追いつくことができるようにすることです。

データ量が急激に増加し、ノード/ノード比（ノードあたり10TB近く）が非常に高い場合、私はI/Oボトルネックを探しています。

乾杯ベン

出典

2016-05-09 05:01:11

おかげでベン、初心者、私はCASSが内部で働いていたかかなり認識していなかったようです;）はい、より多くのデータをロードすると、圧縮が大きなsstablesを作成してしまうことを意味します。したがって、これは、複数のファイルシステムを複数のファイルシステムに分割することを前提としています。スピンドルを使用するのではなく、むしろ使用するFSとvol。そのようなFS（複数可）を複数のスピンドルに分散させることができます。したがって、大きなサイズのファイルでは、すべてのスピンドルが機能します。また、コンパクションに費やされるリソース（concurrent_compactors、compaction_throughput_mb_per_sec）を抑制する必要があるため、通常、少なくとも一部のリソースはクライアントの読み書き操作などのために残ります。 –

保留中の圧縮の急激な増加についてRCを調べる方法

答えて

関連する問題