0

私が見逃したものを理解するのを手伝ってください。LIMIT句とORDER BY DESC句を使用したSELECTで、1 つのクラスター ノードの奇妙な動作が見られます。

SELECT cid FROM test_cf WHERE uid = 0x50236b6de695baa1140004bf ORDER BY tuuid DESC LIMIT 1000;

トレース (一部のみ):

…<br> /10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] に REQUEST_RESPONSE メッセージを送信しています | 2016-02-29 22:17:25.117000 | 10.0.23.15 | 7862
REQUEST_RESPONSE メッセージを /10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] に送信しています | 2016-02-29 22:17:25.136000 | 10.0.25.57 | 6283
REQUEST_RESPONSE メッセージを /10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] に送信しています | 2016-02-29 22:17:38.568000 | 10.0.24.51 | 457931
…

10.0.25.56 - コーディネーター ノード
10.0.23.15、10.0.24.51、10.0.25.57 - データを持つノード

コーディネーターは 10.0.24.51 からの応答を他のノードより 13 秒遅く取得します! なんでそうなの？どうすれば修正できますか？

パーティションキー (uid = 0x50236b6de695baa1140004bf) の行数は約 300 です。

ORDER BY ASC (クラスタリング順序) を使用するか、このパーティション キーの行数より少ないLIMIT値を使用すれば、すべて問題ありません。

Cassandra (v2.2.5) クラスターには 25 個のノードが含まれています。各ノードは約 400Gb のデータを保持します。

クラスタは AWS に配置されます。ノードは、VPC 内の 3 つのサブネットに均等に分散されます。ノードのインスタンスのタイプは c3.4xlarge (16 CPU コア、30GB RAM) です。EBS でバックアップされたストレージ (1 TB GP SSD) を使用します。

キースペース RF は 3 です。

列ファミリー:

CREATE TABLE test_cf (
    uid blob,  
    tuuid timeuuid,  
    cid text,  
    cuid blob,  
    PRIMARY KEY (uid, tuuid)  
) WITH CLUSTERING ORDER BY (tuuid ASC)  
    AND bloom_filter_fp_chance = 0.01  
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'  
    AND comment = ''  
    AND compaction ={'class':'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}  
    AND compression ={'sstable_compression':'org.apache.cassandra.io.compress.LZ4Compressor'}  
    AND dclocal_read_repair_chance = 0.1  
    AND default_time_to_live = 0  
    AND gc_grace_seconds = 86400  
    AND max_index_interval = 2048  
    AND memtable_flush_period_in_ms = 0  
    AND min_index_interval = 128  
    AND read_repair_chance = 0.0  
    AND speculative_retry = '99.0PERCENTILE';

nodetool gcstats (10.0.25.57):

Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms)   GC Reclaimed (MB)         Collections      Direct Memory Bytes
    1208504                 368                4559                  73        553798792712                  58                305691840

nodetool gcstats (10.0.23.15):

Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms)   GC Reclaimed (MB)         Collections      Direct Memory Bytes
    1445602                 369                3120                  57        381929718000                  38                277907601

nodetool gcstats (10.0.24.51):

Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms)   GC Reclaimed (MB)         Collections      Direct Memory Bytes
    1174966                 397               4137                  69       1900387479552                 45                304448986
4

1 に答える 1

0

これは、Cassandra に関連する要因と関連しない要因の両方が原因である可能性があります。

非 Cassandra 固有

  • このノードのハードウェア (CPU/RAM/ディスクの種類 (SSD v 回転式) は、他のノードと比較してどうですか?
  • ネットワークはどのように構成されていますか? このノードへのトラフィックは他のノードより遅いですか? ノード間のルーティングに問題がありますか?
  • このサーバーの負荷は他のノードと比較してどうですか?

カサンドラ固有

  • JVM は適切に構成されていますか? GC は他のノードよりもかなり頻繁に実行されていますか? このノードと他のノードをチェックnodetool gcstatsして比較します。
  • 最近、このノードで圧縮が実行されましたか? 小切手nodetool compactionhistory
  • ディスク上の破損したファイルに問題はありますか?
  • system.log に情報が含まれているかどうかを確認しましたか。

一般的な Linux のトラブルシューティングに加えて、nodetool を使用して特定の C* 機能のいくつかを比較し、相違点を探すことをお勧めします。

https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsNodetool_r.html

于 2016-03-01T13:54:33.730 に答える