高速書き込み中に読み取り速度が低下する 

SSTableが多すぎると、Linuxプラットフォームで読み取り速度が低下することがあります。

SSTableが多すぎると、読み取り速度が低下することがあります。以下の手順に従って、読み取り速度の低下を判断し、修正します。

各テーブルのSSTableの総数を調べます。 
この数値をnodetool tablestatsと照合します。
読み取りごとに探索したSSTableの数を取得します。 
この数値をnodetool tablehistogramsと照合します。中央値が2または3を超えている場合は、問題が生じる可能性があります。
SSTableのフラッシュ頻度が高すぎないことを確認してください。 
debug.logenqueuing flushメッセージを調べ、フラッシュのサイズと頻度を書き留めます。
  • SlabPoolCleanerスレッドによって小さな多数のフラッシュが頻繁にキューに入れられている場合は、memtable_cleanup_thresholdを増やします。

    memtable_cleanup_thresholdの値は、多数の書き込みを受け取っているテーブルの数に反比例するはずです。

  • 予備のメモリーが使用可能な場合は、memtable_heap_space_in_mbまたはmemtable_offheap_space_in_mbを増やすことを検討してください。
  • COMMIT-LOG-ALLOCATORスレッドによってフラッシュがキューに入れられる頻度が高い場合は、commitlog_total_space_in_mbを増やします。

    COMMIT-LOG-ALLOCATORによってキューに入れられているフラッシュの数が、キューの対象となっているフラッシュ総数の少数派になるようにしてください。

  • nodetool compactionstatsを使用して、保留中のコンパクションを確認します。

    フラッシュの頻度が高すぎない場合でも、コンパクションが遅れを取っている可能性があります。保留中のコンパクションの数が多い場合、コンパクションに遅れが生じます。この数は、LeveledCompactionStrategyの推定値に過ぎないので注意してください。

compaction_throughput_mb_per_secがお使いのストレージに適した設定になっていることを確認します。 
回転式ディスクのcompaction_throughput_mb_per_secには、デフォルト値として16 MB/秒が選択されています。SSDでは、128 MB/秒以上の高い設定が使用できます。
  1. nodetool setcompactionthroughputを使用して、この値を一時的に調整します。
  2. iostat -x -t 10を使用して、I/O使用率を確認します。ここには10秒間隔の平均が表示され、タイムスタンプが出力されます。
    • %iowaitが1を超える場合、ノードがI/Oバウンドになり始めていることを示します。
    • awaitで許容されるバウンド(平均待機時間、ミリ秒)は次のとおりです。
      • ほとんどのSSD: 10 ms未満。
      • ほとんどの7200 RPM回転式ディスク: 200 ms未満。
  3. システムに適したスループットが見つかったら、cassandra.yamlでこれを恒久的に設定します。
  4. 必要なコンパクション・スループットにI/Oが追いついていない場合は、より高速なディスクを使用するか、ノードを追加する必要があります。
高いコンパクション・スループットを設定したのに、I/O使用率が低く、コンパクションがまだ追いついていない場合、そのコンパクションはCPUバウンドになっている可能性があります。 

CompactionExecutorスレッドのコアごとのCPU使用率を確認してください。

スレッドがシングル・コアの100%を使用している場合、そのコンパクションはCPUバウンドになっている可能性があります。concurrent_compactorsを増やすと、異なるSSTableセットの複数の同時コンパクションを使用できますが、各SSTableセットのコンパクションは、本質的にはシングルスレッドです。LeveledCompactionStrategy(LCS)を使用している場合、SizeTieredCompactionStrategy(STCS)に切り替えるか、ノードを追加してコンパクションの負荷を分散させる必要があります。

注: 物理CPUコア(ハイパースレッド・コアではない)の数よりも同時接続コンパクターを増やすと、逆効果になる場合があります。コンパクションに使用可能なCPUをすべて使用すると、読み書きを処理するCPUが残らないことになります。コンパクションの遅れを取り戻すと同時に、要求への対応を継続する必要がある場合は、読み取り/書き込みのために1つまたは2つの物理CPUを空けておいてください。
ファイルのキャッシュ(ページ・キャッシュ)に十分な空き領域があることを確認してください。 

free -mコマンドでは、キャッシュに使用可能なメモリー量が表示されます。ファイル・キャッシュでホットな作業セットをメモリーに維持するのに十分なメモリーを確保しておいてください。

SizeTieredCompactionStrategyに切り替えます。
LeveledCompactionStrategy(LCS)を使用していても上記の手順ではうまくいかない場合は、SizeTieredCompactionStrategy(STCS)に切り替えることを検討してください。LCSの方が、STCSに比べてコンパクションに必要なリソースが多くなります。LCSでコンパクションを行って遅れを取っているノードが、STCSを使用することで簡単に遅れを取り戻せることがよくあります。
nodetool tablestats(cfhistograms)
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1(cfhistograms) 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
nodetool tablehistograms
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
   
memtable_cleanup_threshold
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows
memtable_cleanup_threshold
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows
memtable_offheap_space_in_mb
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows
commitlog_total_space_in_mb
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows
nodetool compactionstats
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows
nodetool setcompactionthroughput
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows
concurrent_compactors
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows
LeveledCompactionStrategy(LCS)
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows
SizeTieredCompactionStrategy(STCS)
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows
compaction_throughput_mb_per_sec
Apache Cassandraバージョン
2.1
3.0 Linux
3.x Linux
3.0 Windows
3.x Windows