配置文件和各個表上都有大量設置。盡管默認設置對很多用例都很使用，但有些情況下可能還需要做些改變。
管理性能
設置性能目標
規划一個集群時，要了解這個集群將如何使用，這一點很重要，包括客戶數量，預期使用模式和預計峰值負載時間等。這對規划出事集群容量和集群的擴展會很有用。
性能調優都要做出一些取舍，明確性能目標
- 啟用SSTable壓縮可以節省空間，但要以額外的CPU處理為代價
- 如果限制使用網絡和線程，這可以用來保持網絡和CPU的使用處於控制之下，但代價是會減少吞吐量和增加延遲
- 可以增加或減少分配給特定任務(如讀，寫或合並)的線程數，來影響這個任務相對其他任務的優先級，或者支持額外的客戶
- 可以增加堆的大小來減少查詢時間
性能監控
隨着集群規模的增長，客戶數量的增加以及增加更多的鍵空間和表，對集群的需求可能開始往不同的方向牽引。經常依據集群目標測量集群的性能變得越來越重要。
通過 nodetool tpstats / tbalestats 查看加載和延遲問題
nodetool proxyhistograms 顯示讀請求、寫請求和區間請求的延遲，這里所請求的節點作為協調器。
nodetool tablehistograms 顯示特定表的性能
分析性能問題
當心大分區：除了 nodetool tablehistograms，還可以搜索日志，查找提到"寫大分區" ("Writing large partition") 或 "合並大分區" ("Compacting large partition") 的 WARN 消息來檢測大分區。大分區合並的警告閾值由 cassandra.yaml 文件中的 compaction_large_partition_warning_threshold_mb 屬性設置
跟蹤
通過tracing命令跟蹤了解各個查詢中設計的客戶端與節點之間的通信，以及每一步花費的時間。這會幫助我們了解有關數據模型的設計決策和所選擇的副本因子和一致性級別對性能會有怎樣的影響。
輸出內容：准備語句，讀修復，鍵緩存搜索，memtable和SSTable數據查找，節點間交互等活動以及每一步的響應時間 (單位是微秒)
cqlsh> tracing; Tracing is currently disabled. Use TRACING ON to enable. cqlsh> tracing on; Now Tracing is enabled cqlsh> select * from keyspace1.standard1 limit 2; key | C0 | C1 | C2 | C3 | C4 ------------------------+------------------------------------------------------------------------+------------------------------------------------------------------------+------------------------------------------------------------------------+------------------------------------------------------------------------+------------------------------------------------------------------------ 0x3335503436334b333630 | 0x89a7f8588f1f3866788af519bedb8ff284e72843faa37694fcca88b8e24f3d6861d4 | 0xa9b176a554a1d1c1acb860d9b49e05b4f21ab8b7933357e49e48d353147d7ccf7ba7 | 0xd310294bbc90b9a1a99642d85625744a9df753f9688f18074ecf3ae17d806491ff02 | 0x022c59df825545f71d1cd301919821544eb2125b23f2f31c3addd1aa97c163a3aa44 | 0xf8dabfd49bee232435eabd034263706b6d50417a005f25f4320a88bad0adff847aec 0x4f36393733364b393930 | 0x62cebaf3cf2491d39bae52e3589943737f3c44b02de67dc0f213623412d4167e3b0e | 0x0d01092e67706b72e44ed4774c6a77b63fcda402adf6d8e63048e65f462593e62098 | 0x27ecd293bed41cc177547fac81011e72f4398a22fe74825ec2b2b822e7787e09be69 | 0x3ded968484b698f60b1732b8ab4802520bc653d94084ed8a6434396c62c7a52bec7a | 0xfb1392dbcd6d5d21ed699a61f4a40914d7560cc929fea3168353fee189416bb97045 (2 rows) Tracing session: 1f01b040-4a68-11ea-8692-bffd44047be6 activity | timestamp | source | source_elapsed | client -----------------------------------------------------------------------------------------------------------------------------------+----------------------------+---------------+----------------+--------------- Execute CQL3 query | 2020-02-08 06:42:44.548000 | 192.168.56.12 | 0 | 192.168.56.12 RANGE_SLICE message received from /192.168.56.12 [MessagingService-Incoming-/192.168.56.12] | 2020-02-08 06:32:42.997000 | 192.168.56.13 | 82 | 192.168.56.12 Executing seq scan across 7 sstables for (min(-9223372036854775808), max(3074457345618258602)] [ReadStage-2] | 2020-02-08 06:32:43.002000 | 192.168.56.13 | 5637 | 192.168.56.12 Read 2 live rows and 0 tombstone cells [ReadStage-2] | 2020-02-08 06:32:43.007000 | 192.168.56.13 | 10073 | 192.168.56.12 Enqueuing response to /192.168.56.12 [ReadStage-2] | 2020-02-08 06:32:43.007000 | 192.168.56.13 | 10402 | 192.168.56.12 Sending REQUEST_RESPONSE message to /192.168.56.12 [MessagingService-Outgoing-/192.168.56.12-Small] | 2020-02-08 06:32:43.007000 | 192.168.56.13 | 10789 | 192.168.56.12 Parsing select * from keyspace1.standard1 limit 2; [Native-Transport-Requests-1] | 2020-02-08 06:42:44.549000 | 192.168.56.12 | 188 | 192.168.56.12 Preparing statement [Native-Transport-Requests-1] | 2020-02-08 06:42:44.549000 | 192.168.56.12 | 374 | 192.168.56.12 Computing ranges to query [Native-Transport-Requests-1] | 2020-02-08 06:42:44.549000 | 192.168.56.12 | 665 | 192.168.56.12 Submitting range requests on 4 ranges with a concurrency of 1 (2.0803392E7 rows per range expected) [Native-Transport-Requests-1] | 2020-02-08 06:42:44.549001 | 192.168.56.12 | 845 | 192.168.56.12 Enqueuing request to /192.168.56.13 [Native-Transport-Requests-1] | 2020-02-08 06:42:44.549001 | 192.168.56.12 | 982 | 192.168.56.12 Submitted 1 concurrent range requests [Native-Transport-Requests-1] | 2020-02-08 06:42:44.549001 | 192.168.56.12 | 1168 | 192.168.56.12 Sending RANGE_SLICE message to /192.168.56.13 [MessagingService-Outgoing-/192.168.56.13-Small] | 2020-02-08 06:42:44.550000 | 192.168.56.12 | 1988 | 192.168.56.12 REQUEST_RESPONSE message received from /192.168.56.13 [MessagingService-Incoming-/192.168.56.13] | 2020-02-08 06:42:44.564000 | 192.168.56.12 | 16138 | 192.168.56.12 Processing response from /192.168.56.13 [RequestResponseStage-2] | 2020-02-08 06:42:44.565000 | 192.168.56.12 | 16395 | 192.168.56.12 Request complete | 2020-02-08 06:42:44.565211 | 192.168.56.12 | 17211 | 192.168.56.12 cqlsh> tracing off; Disabled Tracing. cqlsh> tracing ; Tracing is currently disabled. Use TRACING ON to enable.
Cassandra將查詢的結果存儲到 system_traces 鍵空間中。通過修改cassandra.yaml配置中的tracetype_query_ttl 和 tracetype_repair_ttl 屬性配置表的TTL
調優方法
推薦方法，一次修改一個配置參數。
一般情況下，可能只需要增加更多的資源(如內存或額外的節點) 就能恢復性能，不過要確保不能因此遮蓋底層的設計或配置問題。
還有一些情況，可能會發線無法單獨銅鼓哦調優達到期望的目標，而需要改變設計。
配置文件 cassandra.yaml 和 cassandra-env.sh
緩存
緩存可以用來提高讀操作的響應性。需要使用額外的內存來存儲數據，從而盡可能減少必須完成的磁盤讀。隨着緩存大小的增加，可以從內存提供服務的"命中"數也會增加。
緩存策略應該根據一下幾個因素調整：
- 考慮你的查詢，使用最適合這些查詢的緩存類型。
- 考慮堆大小與緩存大小的比值，不要讓緩存占用過多的堆空間
- 考慮行大小與鍵大小的比值，通常鍵要比整個行小得多
鍵緩存
鍵緩存存儲了分區鍵和行索引之間的一個映射。以利於更快的訪問存儲在磁盤上的SSTable。可以對每個表分別配置鍵緩存的使用。
cqlsh> desc table keyspace1.standard1; CREATE TABLE keyspace1.standard1 ( key blob PRIMARY KEY, "C0" blob, "C1" blob, "C2" blob, "C3" blob, "C4" blob ) WITH COMPACT STORAGE 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', 'max_threshold': '32', 'min_threshold': '4'} AND compression = {'enabled': 'false'} AND crc_check_chance = 1.0 AND dclocal_read_repair_chance = 0.1 AND default_time_to_live = 0 AND gc_grace_seconds = 864000 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 = '99PERCENTILE';
由於鍵緩存可以大大提高操作性能，而且不會占用大量額外的內存，所以默認會啟動鍵緩存。
關閉鍵緩存：
cqlsh> alter table keyspace1.standard1 with caching = {'keys':'NONE', 'rows_per_partition': 'NONE'};
key_cache_size_in_mb設置表示將用於鍵緩存的最大內存量，這些內存要由所有的表共享。默認值為總JVM堆的5% 或者 100MB (取二者中較小的一個)
行緩存
行緩存可以緩存整個行，對於頻繁訪問的行，行緩存可以提高讀訪問的速度，但代價是要使用更多的內存。
要小心使用行緩存大小設置，因為很容易導致更多的性能問題。對於小數據集，如果所有行都在內存中，行緩存可以得到非常好的性能結果，而對於更大的數據集，必須從磁盤讀取數據時，這只會使性能下降。
如果表讀操作遠多於寫操作，配置一個非常大的行緩存會不必要的耗費相當多的服務器資源。
默認值NONE，可用的選項是一個正整數或ALL，例子：將行緩存設置為200行
cqlsh> alter table keyspace1.standard1 with caching = {'keys':'NONE', 'rows_per_partition': '200'};
計數器緩存
計數器緩存通過減少對最常訪問的計數器的鎖競爭來提高計數器性能。對於計數器緩存配置，沒有提供為每個表單獨配置的選項
counter_cache_size_in_mb 設置確定了將用於計數器緩存的最大內存量，這將由所有表共享。默認值是總JVM堆的2.5%或者50MB (取二者中較小的一個)
保存緩存設置
- 緩存文件保存在 data/saved_caches 目錄下，會按key_cache_save_period(默認14000/4小時), row_cache_save_period(默認0/禁用), counter_cache_save_period(默認7200/2小時) 屬性指定的間隔 (單位為秒) 寫文件
- 緩存按鍵值索引。文件中保存的鍵的個數由 key_cache_keys_to_save, row_cache_keys_to_save, counter_cache_keys_to_save 屬性指示。
- 通過nodetool管理緩存（重啟時恢復為 cassandra.yaml文件中設置的值）
- 使用invalidatecountercache，invalidatekeycache，invalidaterowcache命令清除緩存。
- 使用setcachecapacity命令覆蓋為鍵緩存和行緩存容量配置的設置
- 使用setcachekeystosave命令覆蓋為保存緩存元素所配置的設置。即一個文件中要保存多少個鍵緩存和行緩存元素
Memtable
Cassandra使用memtable來提高寫操作的速度，對應所存儲的每個表會維護一個memtable。達到提交日志閾值或memtable閾值時，cassandra會把memtable刷新輸出到磁盤(作為SSTable)
Cassandra將memtable存儲在Java堆或堆外(原生)內存中，也可能二者都有。對於堆和堆外內存的限制分別通過屬性memtable_heap_space_in_mb 和 memtable_offheap_sapce_in_mb 設置
默認，Cassandra將這兩個值都設置為cassandra-env.sh文件中設置的總的堆大小的 1/4.
另一個和memtable調優有關的元素是 memtable_flush_writers 默認設置為2，指示了在必要時用來寫memtable的線程數。如果你的數據目錄是ssd，就應該把這個數增加到內核數，但不能超過最大值8.如果有一個很大的堆，把這個數設置得更大可以提高性能，因為線程在磁盤I/O時會阻塞。
還可以通過CQL CREATE TABLE 或 ALTER TABLE 命令啟用哥哥表上的定期刷新輸出。 memtable_flush_period_in_ms 選項可以設置 memtable 刷新輸出到磁盤的間隔。設置這個屬性會帶來可預測的寫I/O，不過也導致更多的SSTable和更頻繁的合並。可能會影響讀性能。默認0表示禁用定期刷新輸出。只是在達到commit log閾值或memtable閾值時才會刷新輸出。
提交日志
提交日志的正常寫操作會阻塞，要求客戶端等待這些寫操作結束，設置允許的提交日志最大值，達到這個規模后就要停止向這個文件追加新的寫操作。而應創建一個新的提交日志文件。這個值用commitlog_segment_size_in_mb屬性設置。默認地，這個值為32MB。
為提交日志分配的總的空間由 commitlog_total_space_in_mb屬性指定。如設置一個較大的值，Cassandra不需要台頻繁的刷新輸出到磁盤。
提交日志會定期刪除，成功地將所追加的所有數據刷新輸出到指定的SSTable后就會刪除。由於這個原因，提交日志不擴展得大到接近SSTable文件的大小。
要想增加提交日志包含的寫操作數量，可以通過commitlog_compression屬性啟用日志壓縮。目前支持的壓縮算法包括 LZ4，Snappy 和 Deflate。使用壓縮的代價是需要額外CPU
還有與提交日志同步操作有關，郵commitlog_sync元素表示。值：periodic 和 batch。默認periodic，表示服務器只按指定的間隔保證寫操作是持久的。這個間隔時間由commitlog_sync_perion_in_ms屬性指定，默認10000(10秒)。倘若服務器設置為只是在周期時間內保證寫操作是持久的，就有可能丟失一些數據，因為在這個周期時間里，那些數據可能還沒有從"后台寫"(write-behind)，緩存同步到磁盤。如果設置為batch，則會阻塞，直到寫操作同步到磁盤(提交日志同步到磁盤完成之前，Cassandra不會確認寫操作完成)，如果要求更快地寫，就會限制它管理自己資源的自由。修改為batch，需要設置commitlog_sync_batch_window_in_ms為一個合理的值，每次同步的間隔時間。
SSTable
Cassandra會一部地向磁盤寫SSTable文件，如果普通硬盤，建議將數據文件和提交日志保存到不同的磁盤上，如果SSD，最好使用同一個磁盤。
從磁盤讀取SSTable文件時，Cassandra使用了一種緩沖緩存，也稱為緩沖池，來幫助減少數據庫文件I/O。這個緩存使用堆外內存，不過它的大小默認為512MB或Java堆的1/4(取二者中較小的一個)。可以使用file_cache_size_in_mb屬性設置這個緩存大小。還可以把buffer_pool_use_heap_if_exhausted設置為true，允許Cassandra在堆外緩存滿時使用Java堆作為緩沖區。
Cassandra在內存中維護SSTable索引摘要來加快對SSTable文件的訪問，默認Java堆的5%分配給這些索引，通過cassandra.yaml中index_summary_capacity_in_mb屬性覆蓋這個設置。為了保持在所分配的限制內，會所見不常讀取的表的相關索引。因為讀操作數可能隨時間變化，會按一定頻率堆磁盤上存儲的文件重建索引。這個頻率由 index_summary_resize_interval_in_minutes屬性指定，默認為60.
Cassandra還提供了一種機制，可以影響為不同表的索引分配的相對空間大小。通過CQL CREATE TABLE 或 ALTER TABLE 命令對表進行設置，min_index_interval (每個SSTable存儲的最小索引條目數) 和 max_index_interval (每個SSTable存儲的最大的索引條目數)
提示移交
協調器節點可以代表一個宕機節點在一定時間內保存數據的一個副本。
hinted_handoff_throttle_in_kb 控制提示傳送時使用的帶寬，或使用nodetool sethintedhandoffthrottleke 來控制。默認1MB/s, 對節點接收提示所需的帶寬設置一個上限。例如在一個3節點的集群中，兩個節點向第三個節點傳送提示，這兩個節點會分別將提示傳送使用的帶寬控制為這個值的一半，512kb/s
3.0版本開始，Cassandra將提示存儲到 hints_directory 屬性指定的一個目錄中。默認 data/hints/。 可以通過 max_hints_file_size_in_mb 屬性設置存儲提示的磁盤空間大小。
nodetool truncatehints 命令，清除等待傳送的提示。提示最好會在 max_hint_window_in_ms 屬性指定的時間之后過期。
合並
Cassandra為合並提供了一些配置，包括一個節點上合並所使用的資源，以及每個表使用的合並策略
SizeTieredCompactionStrategy
STCS是默認是合並策略。這種策略將SSTable分組為層(tier)按大小組織，如果一層以及由足夠數量的SSTableI (默認為4個或更多)，就會運行一個合並，將條目組合為一個更大的SSTable。隨着數據量的增加，會創建越來越多的層。STCS特別適合用於寫密集的表，而對於讀密集的表則不是那么使用，因為某一行的數據可能分布在平均10個左右的SSTable上。
LeveledCompactionStrategy
LCS會創建固定大小的SSTable(默認為5MB)，將他們分組為級(level),每一級包含前一級10倍的SSTable，LCS保證給定的一行在每一級最多出現在一個SSTable中，LCS在I/O上開銷更大，以盡可能減少包含某一行的SSTable個數，給定的一個平均會出現在1.11個SSTable中。如果讀寫比很高或者要求延遲可預測時，應當使用這個策略。如果集群以及是I/O密集的，LCS也不會由太好的表現。如果寫遠遠大於讀，Cassandra可能就難以為繼了。
DateTieredCompactionStrategy
DTCS是2.0.11和2.1.1版本中引入的。這個策略是為了提高時間序列數據的讀性能，特別是訪問模式涉及要訪問最近寫入的數據時。它的做法是將按時間窗SSTable分組，由數據的寫入時間組織。合並只能在這些時間窗內完成。因為DTCS相對較新，而且針對的是一種特定的用例，在使用之前一定要仔細研究。
合並閾值
合並閾值需要逐個表設置。合並閾值是指一個小合並啟動之前隊列中要合並的SSTable數。默認min=4，max=32。太小Cassandra會花大量時間與客戶端爭奪資源，來完成大量頻率而且沒必要的合並。太大，會花費大量的資源一次完成多個合並。
修改合並閾值。通過CQL CREATE TABLE 或 ALTER TABLE命令逐個表的設置。也可以使用 nodetool setcompactionthreshold 進行設置
[cassandra@node2 bin]$ ./nodetool getcompactionthreshold test01 test01 Current compaction thresholds for test01/test01: min = 4, max = 32 [cassandra@node2 bin]$ ./nodetool setcompactionthreshold test01 test01 8 64 [cassandra@node2 bin]$ ./nodetool getcompactionthreshold test01 test01 Current compaction thresholds for test01/test01: min = 8, max = 64
合並操作
合並操作的I/O和CPU開銷都很大，所以Cassandra提供了一種功能可以監控合並過程，並影響合適發生合並。可以使用 nodetool compactionstats 命令監控一個節點上合並的狀態，這會列出每個活躍合並已完成的字節數和總字節數。
如果看到合並堆積，可以使用nodetool getcompactionthroughput 和 setcompactionthroughput 查看和設置Cassandra讀i整個集群應用的合並節流設置。對應配置文件compaction_throughput_mb_per_sec屬性。設置為0會禁用節流控制。不過對於大多數非密集的情況，默認16MB/s 已經足夠了
如果還不能解決問題，可以通過設置配置文件 concurrent_compactors屬性增加用於合並的線程數。或者在運行時可以通過CompactionManagerMBean來設置。這個屬性默認為磁盤數和內核數中的較小值，最小值為2，最大值為8.
很大的合並hi影響集群性能，使用nodetool stop 命令停止一個節點上的所有活躍合並。還可以按ID明確指定停止哪一個合並。折里的ID由nodetool compactionstats輸出得到。Cassandra會重新調度以后再運行這些停止的合並。
可以通過 nodetool compact 命令強制完成一個主合並。手動啟動一個合並之前，記住，合並是一個開銷非常大的操作。取決於所用的合並策略，合並期間nodetool compact 的行為會有所變化。 nodetool compactionhistory 命令會打印已完成的合並的統計信息，包括合並前和合並后的數據大小，以及合並的行數，這個輸出非常詳細。
並發和線程
Cassandra與很多數據庫不同的一點是，相比於讀性能，它可以提供更快的寫性能。關於多少個線程完成讀和寫操作的設置：concurrent_reads 和 concurrent_writes。
concurrent_reads
設置確定節點可以服務多少個並發的讀請求。默認32，不過應該設置為用於數據存儲的硬盤個數 * 16.這是因為數據集大於可用內存時，讀操作是I/O密集型的。
concurrent_writes
這與並發寫服務器的客戶端個數有關。如果Cassandra再支持一個web應用服務器，可以把這個設置從默認的32調整為這個應用服務器連接Cassandra的線程數，再java應用服務器中，通常希望數據庫連接池不超過20或30個線程，不過如果你再使用一個集群中的多個應用服務器，就要把這一點也考慮在內。
concurrent_counter_writes
計數器寫操作，設置cr 和 cw 較小者。
concurrent_materialized_view_writes
物化視圖的寫操作，設置cr 和 cw 較小者。
max_hint_delivery_threads
用於提示傳送的最大線程數
memtable_flush_writers
用於將memtable刷新輸出到磁盤的線程數
concurrent_compactors
用於運行合並的線程數
native_transport_max_threads
用於處理到來CQL請求的最大線程數(還可以注意到類似的屬性rpc_min_threads 和 rpc_max_threads，他們對應以及廢棄的 Thrift 接口)
網絡和超時
節點超時設置
read_request_timeout_in_ms: 默認值 5000/5s 協調器等待讀完成的時間
range_request_timeout_in_ms: 默認值 10000/10s 協調器等待區間讀完成的時間
write_request_timeout_in_ms: 默認值 2000/2s 協調器等待寫完成的時間
counter_write_request_timeout_in_ms: 默認值 5000/5s 協調器等待計數器寫完成的時間
cas_contention_timeout_in_ms: 默認值 1000/1s 協調器繼續重試一個輕量級事務的時間
truncate_request_timeout_in_ms: 默認值 60000/1分鍾 協調器等待刪除完成(包括快照)的時間
request_timeout_in_ms: 默認值 10000/10s 其他各種操作的默認超時時間
streaming_socket_timeout_in_ms: 3600000/1小時 一個節點等待流傳輸完成的時間
cross_node_timeout: 默認值 false 啟用NTP，對於長時間運行的請求，准確的估計系欸掏錢何時超時並更快地釋放資源
stream_throughput_outbound_megabits_per_sec 和 inter_dc_stream_throughput_outbound_megabits_per_sec 屬性分別再單個線程上設置一個節流閥，可以控制將文件傳輸到本地和遠程數據中心其他節點的吞吐量。
hinted_handoff_throttle_in_kb 和 batchlog_replay_throttle_in_kb 屬性指定的值是集群的最大吞吐量
native_transport_max_frame_size_in_mb： 屬性指定默認最大幀大小是256.控制集群客戶端應用數據流。
native_transport_max_concurrent_connections： 屬性限制節點最大並發客戶連接數，默認 -1 (不限制)。如果配置這個值，肯惡搞要確保滿足concurrent_readers 和 concurrent_writers屬性的前提下這個值是由意義的。
native_transport_max_concurrent_connections_per_ip： 限制來自某個源IP地址的並發連接數。默認 -1 (不限制)
內存
默認Cassandra使用以下算法來設置JVM堆的大小: 如果機器RAM小於1GB， 堆設置為RAM的50%。如果機器的RAM大於4GB，堆設置為RAM的25%，最大不超過8GB.
要堆堆大小的最小和最大值調優，可以使用-Xms和-Xmx標志。這些設置應該設置為相同的值，這樣整個堆就會鎖定再內存中，而不會被操作系統患處。不建議設置大於8GB，會歹來更長時間的GC(垃圾回收)
Linux性能監控
https://tobert.github.io/pages/als-cassandra-21-tuning-guide.html