第十二章：Cassandra性能調優--Cassandra：The Definitive Guide 2nd Edition

在本章中，我們將介紹如何調整Cassandra以提高性能。配置文件和各個表中有各種設置。雖然默認設置適用於許多用例，但在某些情況下您可能需要更改它們。在本章中，我們將介紹如何以及爲何進行這些更改。

我們還了解了如何使用Cassandra附帶的cassandra-stress測試工具來生成對Cassandra的負載，並快速瞭解它在壓力測試環境下的行爲。然後我們可以適當調整Cassandra，並確信我們已準備好部署到生產環境。

調節性能

爲了有效地實現和維護集羣中的高性能，將性能管理視爲一個從應用程序的體系結構開始並繼續進行開發和操作的過程是有幫助的。

設定性能目標

在開始任何性能調優工作之前，無論您是剛開始在Cassandra上部署應用程序還是維護現有應用程序，都必須牢記明確的目標。

規劃集羣時，瞭解集羣的使用方式非常重要：客戶端數量，預期使用模式，預計高峯時段等。這將有助於規劃初始集羣容量和規劃集羣增長，我們將在第14章進一步討論。

此規劃工作的一個重要部分是根據吞吐量（每單位時間服務的查詢數）和延遲（完成給定查詢的時間）確定明確的性能目標。

例如，假設我們正在構建一個使用我們在第5章中設計的酒店數據模型的電子商務網站。我們可能會爲集羣上的購物操作設置以下性能目標：

羣集必須從available_ rooms_by_hotel_date表支持每秒30,000次讀取操作，第95百分位讀取延遲爲3 ms。

這是一個包含吞吐量和延遲目標的語句。我們將學習如何使用nodetool tablestats進行測量。

無論您的具體表現目標如何，重要的是要記住，性能調優都是權衡取捨。明確定義的性能目標將幫助您闡明應用程序可接受的權衡。例如：

• 啓用SSTable壓縮以節省磁盤空間，但需要額外的CPU處理。
• 限制網絡使用和線程，可用於控制網絡和CPU利用率，但代價是吞吐量降低和延遲增加。
• 增加或減少分配給特定任務（如讀取，寫入或壓縮）的線程數，以便影響相對於其他任務的優先級或支持其他客戶端。
• 增加堆大小以減少查詢時間。

這些只是您在性能調優中會考慮的一些權衡因素。我們將在本章的其餘部分重點介紹其他內容。

監控性能

隨着集羣規模的增長，客戶端數量的增加，以及更多的密鑰空間和表格的添加，集羣的需求將開始向不同的方向發展。頻繁使用基線來衡量羣集的性能與其目標之間的關係將變得越來越重要。

我們在第10章中瞭解了通過JMX公開的各種指標，包括Cassandra的StorageProxy和各個表的性能相關指標。在該章中，我們還研究了發佈與性能相關的統計信息（如nodetool tpstats和nodetool tablestats）的nodetool命令，並討論了這些命令如何幫助識別加載和延遲問題。

現在我們將看兩個額外的nodetool命令，它們提供格式化爲直方圖的性能統計信息：proxyhistograms和tablehistograms。首先，讓我們檢查nodetool proxyhistograms命令的輸出：

$ nodetool proxyhistograms

proxy histograms
Percentile      Read Latency     Write Latency     Range Latency
                    (micros)          (micros)          (micros)
50%                   654.95              0.00           1629.72
75%                   943.13              0.00           5839.59
95%                  4055.27              0.00          62479.63
98%                 62479.63              0.00         107964.79
99%                107964.79              0.00         129557.75
Min                   263.21              0.00            545.79
Max                107964.79              0.00         155469.30

輸出顯示請求的節點作爲協調器的讀取，寫入和範圍請求的延遲。 輸出以百分位數等級以及以微秒爲單位的最小值和最大值表示。 在多個節點上運行此命令有助於識別羣集中是否存在慢節點。 大範圍延遲（在幾百毫秒或更長時間內）可以指示使用低效範圍查詢的客戶端，例如那些需要ALLOW FILTERING子句或索引查找的查詢。

雖然代理組合圖提供的視圖對於識別一般性能問題很有用，但我們經常需要關注特定表的性能。 這就是nodetool tablehistograms允許我們做的事情。 讓我們看一下這個命令對available_rooms_by_hotel_date表的輸出：

nodetool tablehistograms hotel available_rooms_by_hotel_date

hotel/available_rooms_by_hotel_date histograms
Percentile  SSTables  Write Latency  Read Latency  Partition Size  Cell Count
                      (micros)       (micros)      (bytes)                  
50%         0.00      0.00           0.00          2759            179
75%         0.00      0.00           0.00          2759            179
95%         0.00      0.00           0.00          2759            179
98%         0.00      0.00           0.00          2759            179
99%         0.00      0.00           0.00          2759            179
Min         0.00      0.00           0.00          2300            150
Max         0.00      0.00           0.00          2759            179

此命令的輸出類似。它省略了範圍延遲統計信息，而是提供每個查詢讀取的SSTables計數。提供了分區大小和單元計數，這提供了另一種識別大分區的方法。

重置指標

請注意，在通過3.X系列的Cassandra版本中，報告的指標是自節點啓動以來的生命週期指標。要重置節點上的度量標準，必須重新啓動它。 JIRA問題CASSANDRA-8433要求能夠通過JMX和nodetool重置指標。

熟悉這些指標以及他們告訴您有關羣集的內容後，您應確定要監控的關鍵指標，甚至實施自動警報，以指示您的績效目標未得到滿足。您可以通過DataStax OpsCenter或任何基於JMX的度量框架來完成此任務。

分析性能問題

一直運行良好的集羣的性能隨着時間的推移開始降級並不罕見。當您檢測到性能問題時，您需要快速開始分析，以確保性能不會繼續惡化。在這些情況下，您的目標應該是確定根本原因並解決它。

在本章中，我們將介紹許多配置設置，這些設置可用於在整個集羣空間和表中調整集羣中每個節點的性能。嘗試將性能問題縮小到特定表甚至查詢也很重要。

事實上，數據模型的質量通常是Cassandra集羣性能中最具影響力的因素。例如，導致具有越來越多行的分區的表設計可能開始降低羣集的性能並在失敗的修復中顯示，或者在添加新節點時出現流故障。相反，具有限制性太強的分區鍵的分區可能導致行太窄，需要讀取許多分區以滿足簡單查詢。

當心大分區

除了前面討論的nodetool表組合圖之外，您還可以通過搜索引用“編寫大分區”或“壓縮大分區”的WARN消息的日誌來檢測大分區。壓縮大分區時的警告閾值由cassandra.yaml文件中的compaction_large_partition_warning_ threshold_mb屬性設置。

您還需要學習識別第5章中討論的反模式實例，例如隊列或生成大量邏輯刪除的其他設計方法。

追蹤

如果您可以將搜索範圍縮小到特定表格並查詢問題，則可以使用跟蹤來獲取詳細信息。 跟蹤是一種非常寶貴的工具，用於理解每個查詢中涉及的客戶端和節點之間的通信以及每個步驟所花費的時間。 這有助於我們瞭解我們在數據模型中做出的設計決策的性能影響以及複製因素和一致性級別的選擇。

有幾種方法可以訪問跟蹤數據。 我們首先來看一下cqlsh中跟蹤的工作原理。 首先，我們將啓用跟蹤，然後執行一個簡單的命令：

cqlsh:hotel> TRACING ON
Now Tracing is enabled
cqlsh:hotel> SELECT * from hotels where id='AZ123';

 id    | address | name                            | phone          | pois
-------+---------+---------------------------------+----------------+------
 AZ123 |    null | Super Hotel Suites at WestWorld | 1-888-999-9999 | null

(1 rows)

Tracing session: 6669f210-de99-11e5-bdb9-59bbf54c4f73

 activity           | timestamp                  | source    | source_elapsed
--------------------+----------------------------+-----------+----------------
Execute CQL3 query  | 2016-02-28 21:03:33.503000 | 127.0.0.1 |              0
Parsing SELECT *... | 2016-02-28 21:03:33.505000 | 127.0.0.1 |          41491
...            

爲簡潔起見，我們已經截斷了輸出，但是如果你運行這樣的命令，你會看到諸如準備語句，讀取修復，密鑰緩存搜索，memtables和SSTables中的數據查找，節點之間的交互以及 與每一步相關的時間，以微秒爲單位。

您需要留意需要大量節點間交互的查詢，因爲這些可能表明您的架構設計存在問題。 例如，基於二級索引的查詢可能涉及與羣集中的大多數或所有節點的交互。

完成在cqlsh中使用跟蹤後，可以使用TRACING OFF命令將其關閉。

使用DataStax驅動程序的客戶端也可以使用跟蹤信息。 讓我們修改第8章中的一個示例，瞭解如何通過DataStax Java驅動程序與跟蹤進行交互。 突出顯示的代碼可以跟蹤查詢並打印出跟蹤結果：

SimpleStatement hotelSelect = session.newSimpleStatement(
                "SELECT * FROM hotels WHERE id='AZ123'");
hotelSelect.enableTracing();

ResultSet hotelSelectResult = session.execute(hotelSelect);

QueryTrace queryTrace = hotelSelectResult.getExecutionInfo().getQueryTrace();

System.out.printf("Trace id: %s\n\n", queryTrace.getTraceId());
System.out.printf("%-42s | %-12s | %-10s \n", "activity",
                  "timestamp", "source");

System.out.println("-------------------------------------------" 
 + "--------------+------------");                 

SimpleDateFormat dateFormat = new SimpleDateFormat("HH:mm:ss.SSS");

for (QueryTrace.Event event : queryTrace.getEvents()) {
  System.out.printf("%42s | %12s | %10s\n",    
    event.getDescription(),
    dateFormat.format((event.getTimestamp())),
    event.getSource());
}

使用enableTracing（）操作在每個Statement或PreparedStatement上單獨啓用跟蹤。 要獲取查詢的跟蹤，我們查看查詢結果。 您可能已經注意到，在我們之前的示例中，Session.execute（）操作始終返回ResultSet對象，即使對於SELECT查詢以外的查詢也是如此。 這使我們能夠通過ExecutionInfo對象獲取有關請求的元數據，即使沒有返回結果也是如此。 此元數據包括已實現的一致性級別，協調器節點和查詢中涉及的其他節點，以及有關跟蹤和分頁的信息。

執行此代碼會產生與我們在cqlsh中看到的輸出非常相似的輸出：

Trace id: 58b22960-90cb-11e5-897a-a9fac1d00bce

activity                                   | timestamp    | source    
-------------------------------------------+--------------+------------
   Parsing SELECT * FROM hotels WHERE id=? | 20:44:34.550 | 127.0.0.1
                       Preparing statement | 20:44:34.550 | 127.0.0.1
                      Read-repair DC_LOCAL | 20:44:34.551 | 127.0.0.1
Executing single-partition query on hotels | 20:44:34.551 | 127.0.0.1
              Acquiring sstable references | 20:44:34.551 | 127.0.0.1
                 Merging memtable contents | 20:44:34.551 | 127.0.0.1
               Merging data from sstable 3 | 20:44:34.552 | 127.0.0.1
    Bloom filter allows skipping sstable 3 | 20:44:34.552 | 127.0.0.1
               Merging data from sstable 2 | 20:44:34.552 | 127.0.0.1
    Bloom filter allows skipping sstable 2 | 20:44:34.552 | 127.0.0.1
         Read 1 live and 0 tombstone cells | 20:44:34.552 | 127.0.0.1

DataStax DevCenter也支持跟蹤，默認情況下啓用跟蹤。 您可以通過選擇屏幕中下方的“查詢跟蹤”選項卡立即查看您在DevCenter中發出的任何請求的跟蹤，如圖12-1所示。 （“連接”，“CQL腳本”，“架構”和“大綱”面板已經最小化以實現可讀性。）

您可以通過nodetool settraceprobability命令配置各個節點以跟蹤其部分或全部查詢。此命令採用介於0.0（默認值）和1.0之間的數字，其中0.0禁用跟蹤，1.0跟蹤每個查詢。這不會影響客戶端請求的單個查詢的跟蹤。在改變跟蹤概率時要小心，因爲典型的跟蹤會話涉及10次或更多次寫入。將跟蹤級別設置爲1.0可能會使繁忙的羣集過載，因此0.01或0.001等值通常是合適的。

痕跡不是永恆的

Cassandra將查詢跟蹤結果存儲在system_traces鍵空間中。自2.2版本發佈以來，Cassandra還使用跟蹤來存儲修復操作的結果。 Cassandra限制這些表上的TTL，以防止它們隨着時間的推移填滿磁盤。您可以通過編輯cassandra.yaml文件中的tracetype_query_ttl和tracetype_repair_ttl屬性來配置這些TTL值。

調整方法

一旦確定了與您既定目標相關的性能問題的根本原因，就應該開始調整性能了。調整Cassandra性能的建議方法是一次更改一個配置參數並測試結果。

限制調整時所做的配置更改量非常重要，這樣您就可以清楚地識別每個更改的影響。您可能需要多次重複更改過程，直到達到所需的性能目標。

在某些情況下，您可以通過添加更多資源（如內存或額外節點）來恢復性能，但請確保您不僅僅是屏蔽底層設計或配置問題。在其他情況下，您可能會發現通過單獨調整無法達到預期目標，並且需要進行設計更改。

考慮到這種方法，讓我們看一下您可以配置來調整Cassandra集羣的各種選項。我們將在cassandra.yaml和cassandra-env.sh文件中突出顯示節點配置屬性，以及使用CQL在各個表上配置的選項。

高速緩存

緩存用於提高對讀取操作的響應性。附加內存用於保存數據，以最大限度地減少必須執行的磁盤讀取次數。隨着緩存大小的增加，可以從內存中提供的“命中”數量也會增加。

Cassandra內置了三個緩存：密鑰緩存，行緩存和計數器緩存。行緩存爲每個分區緩存可配置的行數。如果您對給定表使用行緩存，則也不需要在其上使用密鑰緩存。

因此，您的緩存策略應根據以下幾個因素進行調整：

• 考慮您的查詢，並使用最適合您的查詢的緩存類型。
• 考慮堆大小與高速緩存大小的比率，並且不允許高速緩存壓倒堆。
• 根據鍵的大小考慮行的大小。 通常，鍵將比整行小得多。

讓我們考慮每個緩存的一些特定調整和配置選項。

密鑰緩存

Cassandra的密鑰緩存存儲分區鍵到行索引條目的映射，有助於更快地讀取存儲在磁盤上的SSTable。 我們可以基於每個表配置密鑰緩存的使用。 例如，讓我們使用cqlsh來檢查酒店表上的緩存設置：

cqlsh:hotel> DESCRIBE TABLE hotels;

CREATE TABLE hotel.hotels (
    id text PRIMARY KEY,
    address frozen<address>,
    name text,
    phone text,
    pois set<text>
) WITH bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
  ...

因爲密鑰緩存大大增加了讀取而不消耗大量額外內存，所以默認情況下啓用它; 也就是說，如果在創建表時未指定值，則啓用密鑰緩存。 我們可以使用ALTER TABLE命令禁用此表的密鑰緩存：

cqlsh:hotel> ALTER TABLE hotels 
   WITH caching = { 'keys' : 'NONE', 'rows_per_partition' : 'NONE' };

keys屬性的合法選項是ALL或NONE。

key_cache_size_in_mb設置指示將用於密鑰緩存的最大內存量，該緩存在所有表中共享。默認值是總JVM堆的5％，或100 MB，以較小者爲準。

行緩存

行緩存緩存整行，並且可以加快頻繁訪問的行的讀訪問，但代價是更多的內存使用。

您需要仔細使用行緩存大小設置，因爲這很容易導致比解決方案更多的性能問題。在許多情況下，當所有行都在內存中時，行緩存可以爲小數據集產生令人印象深刻的性能結果，只有在必須從磁盤讀取數據時纔會在較大的數據集上降級。

如果您的表讀取的次數遠遠超過寫入次數，那麼配置過大的行緩存將不必要地消耗大量的服務器資源。如果您的表具有較低的讀寫比率，但其中包含大量數據的行（數百列），那麼在設置行緩存大小之前，您需要進行一些數學運算。除非你有一些遭受重創的行和其他受到很少打擊的行，否則你不會在這裏看到太大的提升。

由於這些原因，行緩存往往比密鑰緩存產生更少的好處。您可能希望探索操作系統支持的文件緩存功能，以替代行緩存。

與密鑰緩存一樣，我們可以基於每個表配置行緩存的使用。 rows_per_partition設置指定每個分區將緩存的行數。默認情況下，此值設置爲NONE，表示不會緩存任何行。其他可用選項是正整數或ALL。以下CQL語句將行緩存設置爲200行：

cqlsh:hotel> ALTER TABLE hotels
   WITH caching = { 'keys' : 'NONE', 'rows_per_partition' : '200' };

行緩存的實現可通過row_cache_class_name屬性插入。這默認爲org.apache.cassandra.OHCProvider類實現的堆外緩存提供程序。之前的實現是SerializingCacheProvider。

計數器緩存

計數器高速緩存通過減少最常訪問的計數器的鎖爭用來提高計數器性能。配置計數器緩存沒有per-table選項。

counter_cache_size_in_mb設置確定將用於計數器緩存的最大內存量，該緩存在所有表中共享。默認值是總JVM堆的2.5％，或50 MB，以較小者爲準。

保存的緩存設置

Cassandra提供了定期將緩存保存到磁盤的功能，以便在啓動時可以將它們作爲快速加熱緩存的方式進行讀取。所有三種緩存類型中保存的緩存設置類似：

緩存文件保存在saved_caches屬性指定的目錄下。文件以key_ cache_ save_period，row_cache_save_period和counter_cache_ save_period指定的間隔（秒）寫入，默認分別爲14000（4小時），0（禁用）和7200（2小時）。
高速緩存由鍵值索引。要在文件中保存的密鑰數由key_cache_keys_to_save，row_cache_keys_to_save和counter_ cache_ keys_to_save屬性指示。

通過nodetool管理緩存

Cassandra還提供了通過nodetool管理緩存的功能：

• 您可以使用invalidatekeycache，使rowcache無效和invalidatecountercache命令清除緩存。
• 使用setcachecapacity命令覆蓋已配置的密鑰和行緩存容量設置。
• 使用setcachekeystosave命令覆蓋已配置的設置，以保存要保存到文件的密鑰和行緩存元素的數量。

請記住，這些設置將恢復爲節點重新啓動時cassandra.yaml文件中設置的值。

Memtables

Cassandra使用memtables加速寫入，保存與其存儲的每個表相對應的memtable。當達到提交日誌閾值或可記錄閾值時，Cassandra將memtables作爲SSTables刷新到磁盤。

Cassandra將memtables存儲在Java堆，堆外（本機）內存或兩者上。可以通過屬性memtable_heap_space_in_mb和memtable_offheap_space_in_mb分別設置堆和堆外內存的限制。默認情況下，Cassandra將每個值設置爲cassandra-env.sh文件中設置的總堆大小的1/4。爲memtables分配內存會減少可用於緩存和其他內部Cassandra結構的內存，因此請仔細調整並以較小的增量進行調整。

您可以通過memtable_allocation_type屬性影響Cassandra如何分配和管理內存。此屬性配置另一個Cassandra的可插入接口，選擇抽象類org.apache.cassandra.utils.memory.MemtablePool的哪個實現用於控制每個memtable使用的內存。默認值heap_buffers使Cassandra使用Java New I / O（NIO）API在堆上分配memtables，而offheap_buffers使用Java NIO在堆上和堆外分配每個memtable的一部分。 offheap_objects直接使用本機內存，使得Cassandra完全負責內存管理和memtable內存的垃圾收集。這是一個記錄較少的功能，因此最好堅持使用默認值，直到您獲得更多經驗。

調整memtables的另一個元素是memtable_flush_writers。此設置默認爲2，表示在必要時用於寫出memtables的線程數。如果您的數據目錄由SSD支持，則應將其增加到核心數，而不超過最大值8.如果您有一個非常大的堆，它可以提高性能以將此計數設置得更高，因爲這些線程被阻止在磁盤I / O期間。

您還可以通過CQL CREATE TABLE或ALTER TABLE命令在每個表上啓用計量刷新。 memtable_flush_period_in_ms選項設置將memtable刷新到磁盤的時間間隔。

設置此屬性會導致更可預測的寫入I / O，但也會導致更多SSTable和更頻繁的壓縮，從而可能影響讀取性能。默認值0表示禁用定期刷新，並且只會根據提交日誌閾值或達到可記憶閾值進行刷新。

提交日誌

作爲處理更新操作的一部分，Cassandra寫入了兩組文件：提交日誌和SSTable文件。需要考慮它們的不同目的，以便了解在配置期間如何對待它們。

請記住，提交日誌可以被視爲短期存儲，有助於確保在將memtables刷新到磁盤之前，如果節點崩潰或關閉，數據不會丟失。那是因爲重新啓動節點時，會重播提交日誌。實際上，這是唯一一次讀取提交日誌;客戶從不讀它。但是對提交日誌的正常寫入操作會阻塞，因此會損壞性能以要求客戶端等待寫入完成。

您可以設置允許提交日誌在停止向文件追加新寫入並創建新文件之前增長的大小值。使用commitlog_segment_size_in_mb屬性設置此值。默認情況下，該值爲32 MB。這類似於在日誌記錄引擎（如Log4J或Logback）上設置日誌輪換。

分配給提交日誌的總空間由commitlog_total_ space_in_mb屬性指定。將此值設置爲較大值意味着Cassandra需要不太頻繁地將表刷新到磁盤。

在將所有附加數據成功刷新到專用SSTable文件之後，會定期刪除提交日誌。因此，提交日誌不會增長到接近SSTable文件大小的任何位置，因此磁盤不需要那麼大;在硬件選擇期間需要考慮這一點。

要增加提交日誌可以容納的寫入量，您需要通過commitlog_compression屬性啓用日誌壓縮。支持的壓縮算法是LZ4，Snappy和Deflate。使用壓縮需要額外的CPU時間來執行壓縮。

其他設置與提交日誌同步操作有關，由commitlog_sync元素表示。有兩種可能的設置：定期和批量。默認值爲periodic，這意味着服務器將僅在指定的時間間隔內使寫入持久。間隔由commitlog_sync_period_in_ms屬性指定，默認爲10000（10秒）。

爲了保證Cassandra集羣的耐用性，您可能需要檢查此設置。當服務器設置爲定期持久寫入時，您可能會丟失尚未從後寫高速緩存同步到磁盤的數據。

如果您的提交日誌設置爲批處理，它將阻塞，直到寫入同步到磁盤（在提交日誌完全同步到磁盤之前，Cassandra不會確認寫入操作）。改變這個值需要採取一些性能指標，因爲這裏有必要的權衡：迫使Cassandra立即編寫，限制了它自由管理自己的資源。如果將commitlog_sync設置爲batch，則需要爲commit_log_ sync_batch_window_in_ms提供合適的值，其中ms是每次同步工作之間的毫秒數。

SSTables

與提交日誌不同，Cassandra異步將SSTable文件寫入磁盤。如果您使用的是硬盤驅動器，建議您將數據文件和提交日誌存儲在不同的磁盤上以獲得最佳性能。如果要在固態驅動器（SSD）上進行部署，則可以使用相同的磁盤。

與許多數據庫一樣，Cassandra尤其依賴於硬盤的速度和CPU的速度。爲了利用Cassandra高度併發的結構，擁有多個處理核心而不是一個或兩個非常快的處理核心更爲重要。因此，如果您能負擔得起，請確保QA和生產環境能夠獲得最快的磁盤 - 固態硬盤。如果您正在使用硬盤，請確保至少有兩個硬盤，以便您可以將提交日誌文件和數據文件存儲在不同的磁盤上，從而避免競爭I / O時間。

從磁盤讀取SSTable文件時，Cassandra使用緩衝區緩存（也稱爲緩衝池）來幫助減少數據庫文件I / O.此緩存使用堆外內存，但其大小默認爲512 MB，或Java堆的1/4，以較小者爲準。您可以使用cassandra.yaml中的file_cache_size_in_mb屬性設置緩存大小。通過將buffer_pool_use_heap_if_exhausted設置爲true，您還可以允許Cassandra在堆外緩存已滿時將Java堆用於緩衝區。

正如我們在第9章中討論的那樣，Cassandra在內存中維護SSTable索引摘要，以加快對SSTable文件的訪問。默認情況下，Cassandra將5％的Java堆分配給這些索引，但您可以通過cassandra.yaml中的index_summary_capacity_in_mb屬性覆蓋它。爲了保持在分配的限制範圍內，Cassandra將縮小與不常讀取的表相關聯的索引。由於讀取速率可能會隨時間發生變化，因此Cassandra還會以index_ summary_ resize_interval_in_minutes屬性指定的頻率重新採樣存儲在磁盤上的文件的索引，默認值爲60。

Cassandra還提供了一種機制來影響分配給不同表的索引的相對空間量。這是通過min_index_ interval和max_index_interval屬性完成的，可以通過CQL CREATE TABLE或ALTER TABLE命令設置這些屬性。這些值指定每個SSTable存儲的索引條目的最小和最大數量。

hinted handoff

提示切換是Cassandra提供的幾種機制之一，用於在整個羣集中保持數據同步。正如我們之前所瞭解到的，協調器節點可以代表節點停留一段時間的數據副本。我們可以根據我們願意用來存儲提示的磁盤空間量以及節點重新聯機時提供的提示速度來調整提示切換。

我們可以使用屬性hinted_handoff_throttle_in_kb控制提示傳遞的帶寬利用率，或者在運行時通過nodetool sethintedhandoff throttlekb控制。

此限制限制的默認值爲1024或1 MB /秒，用於設置接收提示的節點所需帶寬的上限閾值。例如，在三個節點的集羣中，向第三個節點傳遞提示的兩個節點中的每一個都會將其提示傳遞限制爲該值的一半，或512KB /秒。

請注意，配置此限制與配置其他Cassandra功能略有不同，因爲接收提示的節點將觀察到的行爲完全基於其他節點上的屬性設置。您肯定希望在羣集中同步使用這些設置的相同值以避免混淆。

在3.0之前的版本中，Cassandra將提示存儲在未複製到其他節點的表中，但從3.0版本開始，Cassandra將提示存儲在hints_directory屬性指定的目錄中，該屬性默認爲Cassandra下的data / hints目錄安裝。您可以通過max_hints_file_size_in_mb屬性設置專用於提示的磁盤空間量上限。

您可以使用帶有IP地址或主機名列表的nodetool truncatehints命令清除等待傳遞到一個或多個節點的任何提示。提示最終在max_hint_window_in_ms屬性表示的值之後到期。

正如我們在第10章中所學到的，也可以完全啓用或禁用提示切換。雖然有些人會將其用作節省磁盤和帶寬的方法，但通常情況下，提示的切換機制與額外的相比不會消耗大量資源。它有助於提供一致性，特別是與修復節點的成本相比。

壓實

Cassandra提供壓縮的配置選項，包括節點上壓縮使用的資源，以及用於每個表的壓縮策略。

爲表格選擇正確的壓縮策略當然可以成爲提高性能的一個因素。讓我們回顧一下可用的策略，並討論何時應該使用它們。

• SizeTieredCompactionStrategy
  SizeTieredCompactionStrategy（STCS）是默認的壓縮策略，在大多數情況下應該使用它。該策略將SSTable分爲按大小組織的層。如果層中有足夠數量的SSTable（默認爲4個或更多），則運行壓縮以將它們組合成更大的SSTable。隨着數據量的增長，會創建越來越多的層。 STCS對於寫入密集型表執行得特別好，但對於讀密集型表而言則較少，因爲特定行的數據可能分佈在平均10個左右的SSTable上。

• LeveledCompactionStrategy

  LeveledCompactionStrategy（LCS）創建固定大小的SSTable（默認爲5 MB）並將它們分組爲級別，每個級別的SSTable數量是前一級別的10倍。 LCS保證給定行每個級別最多出現一個SSTable。 LCS在I / O上花費額外的精力來最小化一行中出現的SSTable數量;給定行的平均SSTable數爲1.11。如果需要高讀寫比率或可預測的延遲，則應使用此策略。如果羣集已經受I / O限制，LCS往往不會表現得那麼好。如果寫作主導讀取，卡桑德拉可能很難跟上。

• DateTieredCompactionStrategy

  DateTieredCompactionStrategy（DTCS）是在2.0.11和2.1.1版本中引入的。它旨在提高時間序列數據的讀取性能，特別是涉及訪問最近寫入的數據的訪問模式。它的工作原理是在由數據寫入時間組織的窗口中對SSTable進行分組。壓縮僅在這些窗口中執行。由於DTCS相對較新且針對特定用例，因此請確保在使用之前仔細研究。

每種策略都有自己的特定參數，可以進行調整。有關詳細信息，請查看發行版的文檔。
使用Write Survey模式測試壓縮策略

如果您想爲表使用不同的壓縮策略進行測試，則無需在整個羣集上更改它以查看其工作原理。相反，您可以創建在寫入調查模式下運行的測試節點，以查看新壓

縮策略的工作方式。

爲此，請將以下選項添加到測試節點的cassandra-env.sh文件中：

JVM_OPTS =“$ JVM_OPTS -Dcassandra.write_survey = true”
JVM_OPTS =“$ JVM_OPTS -Djoin_ring = false”

一旦節點啓動，您就可以訪問org.apache.cassandra.db> Tables下的表的org.apache.cassandra.db.ColumnFamilyStoreMBean，以便配置壓縮策略。將CompactionStrategyClass屬性設置爲完全限定的壓縮策略類名稱。

更改此配置後，通過nodetool join將節點添加到環中，以便它可以開始接收寫入。寫入測試節點會對集羣施加最小的額外負載，並且不計入一致性級別。您現在可以使用nodetool tablestats和tablehistograms監視對節點的寫入性能。

您可以通過停止節點，將其作爲獨立計算機啓動，然後測試節點上的讀取性能來測試新壓縮策略對讀取的影響。

寫入調查模式對於測試其他配置更改甚至是新版本的Cassandra也很有用。

另一個每表設置是壓縮閾值。 壓縮閾值是指在實際啓動次要壓縮之前要壓縮的隊列中的SSTable數。 默認情況下，最小數量爲4，最大值爲32.您不希望此數字太小，或者Cassandra會花時間與客戶爭奪資源以執行許多頻繁的，不必要的壓縮。 您也不希望這個數字太大，或者Cassandra可能會花費大量資源同時執行多個壓縮，因此可用於客戶端的資源更少。

使用CQL CREATE TABLE或ALTER TABLE命令爲每個表設置壓縮閾值。 但是，您可以使用nodetool getcompactionthreshold或setcompactionthreshold命令檢查或覆蓋特定節點的此設置：

$ nodetool getcompactionthreshold hotel hotels
Current compaction thresholds for hotel/hotels:
 min = 4,  max = 32
$ nodetool setcompactionthreshold hotel hotels 8 32

壓縮在I / O和CPU方面可能非常密集，因此Cassandra能夠監控壓實過程並影響壓縮發生的時間。

您可以使用nodetool compactionstats命令監視節點上的壓縮狀態，該命令列出了每個活動壓縮的已完成字節和總字節數（爲簡潔起見，我們省略了ID列）

$ nodetool compactionstats

pending tasks: 1
   id  compaction type  keyspace  table   completed  total      unit   progress
  ...  Compaction       hotel     hotels  57957241   127536780  bytes  45.44%
Active compaction remaining time :   0h00m12s

如果您看到掛起的壓縮開始堆疊，則可以使用nodetool命令getcompactionthroughput和setcompactionthroughput來檢查和設置Cassandra應用於羣集中壓縮的限制。這對應於cassandra.yaml文件中的屬性compaction_throughput_mb_per_sec。將此值設置爲0會完全禁用限制，但對於大多數非寫入密集型情況，默認值16 MB / s就足夠了。

如果這不能解決問題，可以通過在cassandra.yaml文件中設置concurrent_compactors屬性或在運行時通過CompactionManagerMBean來增加專用於壓縮的線程數。此屬性默認爲磁盤數和核心數的最小值，最小值爲2，最大值爲8。

儘管不常見，但是大型壓縮可能會對羣集的性能產生負面影響。您可以使用nodetool stop命令停止節點上的所有活動壓縮。您還可以通過ID識別要停止的特定壓縮，其中ID是從compactionstats輸出中獲取的。 Cassandra將重新安排任何已停止的壓縮以便稍後運行。

您可以通過nodetool compact命令強制執行主要壓縮。在手動啓動主要壓縮之前，請記住這是一項昂貴的操作。壓縮期間nodetool compact的行爲取決於使用的壓縮策略。我們將在第14章討論每種壓縮策略對磁盤使用的影響。

nodetool compactionhistory命令打印有關已完成壓縮的統計信息，包括壓縮前後的數據大小和合並的行數。輸出非常詳細，所以我們在這裏省略了它。

併發和線程

Cassandra與許多數據存儲的不同之處在於它提供比讀取性能更快的寫入性能。有兩個設置與多少線程可以執行讀寫操作有關：concurrent_reads和concurrent_writes。一般來說，Cassandra開箱即用的默認值非常好。

concurrent_reads設置確定節點可以服務的同時讀取請求數。默認值爲32，但應設置爲用於數據存儲的驅動器數量×16。這是因爲當數據集大於可用內存時，讀取操作受I / O限制。

concurrent_writes設置的行爲有所不同。這應該與將同時寫入服務器的客戶端數量相關聯。如果Cassandra支持Web應用程序服務器，您可以將此設置從其默認值32調整爲與應用程序服務器可用於連接到Cassandra的線程數相匹配。在Java應用程序服務器中，更喜歡不超過20或30的數據庫連接池，但如果您在羣集中使用多個應用程序服務器，則還需要將其考慮在內。

另外兩個設置 - concurrent_counter_writes和concurrent_materialized_view_writes - 可用於調整特殊形式的寫入。因爲計數器和物化視圖寫入都涉及寫入之前的讀取，所以最好將其設置爲concurrent_reads和concurrent_writes中的較低者。

cassandra.yaml文件中還有其他幾個屬性，用於控制分配給線程池的線程數，這些線程池在Cassandra的SEDA方法中實現了各個階段。我們已經看過其中的一些了，但這裏有一個總結：

• max_hints_delivery_threads
  專用於提示傳遞的最大線程數
• memtable_flush_writers
  專用於將memtables刷新到磁盤的線程數
• concurrent_compactors
  專用於運行壓縮的線程數
  native_transport_max_threads
  用於處理傳入CQL請求的最大線程數（您可能還會注意到類似的屬性rpc_min_threads和rpc_ max_ threads，這些屬性適用於已棄用的Thrift接口）

請注意，其中一些屬性允許Cassandra動態分配和釋放線程達到最大值，而其他屬性則指定靜態線程數。向上或向下調整這些屬性會影響Cassandra如何使用其CPU時間以及它可以爲各種活動投入多少I / O容量。

網絡和超時

由於Cassandra是一個分佈式系統，它提供了處理網絡和節點問題的機制，包括重試，超時和限制。我們已經討論了Cassandra實現重試邏輯的幾種方法，例如DataStax客戶端驅動程序中的RetryPolicy，以及驅動程序和節點中的推測性讀取執行。

現在讓我們來看看Cassandra提供的超時機制，以幫助它避免無限期地掛起等待其他節點做出響應。表12-1中列出的超時屬性在cassandra.yaml文件中設置。

Property Name	Default Value	Description
read_request_timeout_in_ms	5000 (5 seconds)	How long the coordinator waits for read operations to complete
range_request_timeout_in_ms	10000 (10 seconds)	How long the coordinator should wait for range reads to complete
write_request_timeout_in_ms	2000 (2 seconds)	How long the coordinator should wait for writes to complete
counter_write_request_timeout_in_ms	5000 (5 seconds)	How long the coordinator should wait for counter writes to complete
cas_contention_timeout_in_ms	1000 (1 second)	How long a coordinator should continue to retry a lightweight transaction
truncate_request_timeout_in_ms	60000 (1 minute)	How long the coordinator should wait for truncates to complete (including snapshot)
streaming_socket_timeout_in_ms	3600000 (1 hour)	How long a node waits for streaming to complete

request_timeout_in_ms 10000 (10 seconds) The default timeout for other, miscellaneous operations

這些超時的值通常是可以接受的，但您可能需要針對您的網絡環境進行調整。

與超時相關的另一個屬性是cross_node_timeout，默認爲false。如果在您的環境中配置了NTP，請考慮啓用此功能，以便節點可以更準確地估計協調器何時超時長時間運行請求並更快地釋放資源。

Cassandra還提供了幾個屬性，允許您限制它將用於各種操作的網絡帶寬量。調整這些可以防止Cassandra淹沒您的網絡，但代價是花費更長的時間來完成這些任務。例如，stream_throughput_outbound_megabits_per_sec和inter_dc_stream_throughput_outbound_megabits_per_sec屬性分別指定流式文件傳輸到本地和遠程數據中心中的其他節點的每線程限制。

暗示切換和批量日誌重放的限制工作略有不同。 hinted_handoff_throttle_in_kb和batchlog_ replay_ throttle_in_kb指定的值被視爲羣集的最大吞吐量值，因此根據以下公式按比例分佈在節點上：

$T_x = \frac{T_t}{N_n - 1}$

也就是說，節點x（Tx）的吞吐量等於總吞吐量（Tt）除以集羣中節點數（Nn）的1。

最後，有幾個屬性可用於限制每個節點上本機CQL端口的流量。在您無法直接控制羣集的客戶端應用程序的情況下，這些可能很有用。 native_transport_max_frame_size_in_mb屬性指定的默認最大幀大小爲256.節點將拒絕大於此的幀請求。

節點還可以通過native_transport_max_concurrent_connections屬性限制最大併發客戶端連接數，但默認值爲-1（無限制）。如果配置此值，則需要根據concurrent_readers和concurrent_writers屬性確保它有意義。

要限制來自單個源IP地址的同時連接數，請配置native_transport_max_concurrent_connections_per_ip屬性，默認爲-1（無限制）。

JVM設置

Cassandra允許您配置各種選項，以瞭解服務器JVM應如何啓動，應分配多少Java內存等等。在本節中，我們將介紹如何調整啓動。

如果您使用的是Windows，則啓動腳本稱爲cassandra.bat，而在Linux上則爲cassandra.sh。您可以通過簡單地執行此文件來啓動服務器，該文件設置了幾個默認值。但conf目錄中還有另一個文件，允許您配置與Cassandra啓動方式相關的各種設置。此文件名爲cassandra-env.sh（Windows上爲cassandra-env.ps1），它將某些選項（如JVM設置）分隔爲不同的文件，以便於更新。

嘗試調整在啓動時傳遞給JVM的選項以獲得更好的性能。關於cassandra-env.sh中包含的關鍵JVM選項以及如何調整它們的指導原則將立即進行討論。如果要更改任何這些值，只需在文本編輯器中打開cassandra-env.sh文件，更改值，然後重新啓動。

jvm.options文件

Cassandra 3.0版本在conf目錄中引入了另一個名爲jvm.options的設置文件。此文件的目的是將與堆大小和垃圾回收相關的JVM設置從cassandra.in.sh文件移動到單獨的文件，因爲這些是最常調整的屬性。 cassandra-env.sh文件包含（源代碼）jvm.options和cassandra.in.sh。

內存

默認情況下，Cassandra使用以下算法來設置JVM堆大小：如果計算機的RAM小於1 GB，則堆將設置爲RAM的50％。如果機器具有超過4 GB的RAM，則堆設置爲RAM的25％，上限爲8 GB。要調整最小和最大堆大小，請使用-Xms和-Xmx標誌。應將這些值設置爲相同的值，以允許整個堆鎖定在內存中而不會被操作系統換出。如果使用並行標記掃描（CMS）垃圾收集器，則不建議將堆設置爲大於8GB，因爲大於此值的堆大小往往會導致更長的GC暫停。

在進行性能調優時，最好只設置堆最小和最大選項，而不是先設置其他任何選項。只有在您的環境中使用實際情況並在堆分析工具的幫助下進行一些性能基準測試並觀察特定應用程序的行爲之後，您才應該深入調整更高級的JVM設置。如果您調整JVM選項並看到一些成功，請不要太興奮。您需要在真實條件下進行測試。

一般情況下，如果遇到內存不足錯誤（這是cassandra-env.sh中的默認值，由-XX設置），您可能希望確保已指示堆轉儲其狀態： + HeapDumpOnOutOfMemory選項。如果您開始遇到內存不足錯誤，這只是一個很好的做法。

垃圾收集

Java堆大致分爲兩個對象空間：年輕和舊。年輕空間被細分爲一個用於新對象分配（稱爲“伊甸園空間”），另一個用於仍在使用的新對象（“倖存者空間”）。

Cassandra在年輕一代使用並行複製收集器;這是通過-XX：+ UseParNewGC選項設置的。較舊的對象仍然有一些參考，因此倖存了幾個垃圾收集，因此倖存者比率是堆的年輕對象部分中的伊甸園空間與倖存者空間的比率。增加比率對於具有大量新對象創建和低對象保留的應用程序是有意義的;減少它對於具有較長壽命對象的應用程序是有意義的。 Cassandra通過-XX：SurvivorRatio選項將此值設置爲8，這意味着伊甸園與倖存者空間的比率爲1：8（每個倖存者空間將是伊甸園大小的1/8）。這相當低，因爲對象在memtables中的壽命更長。

每個Java對象的標題中都有一個age字段，表示在年輕代空間中複製了多少次。當對象在年輕代垃圾收集中存活時，它們被複制到新的空間中，並且這種複製具有成本。由於長生命對象可能會被多次複製，因此調整此值可以提高性能。默認情況下，Cassandra通過-XX：MaxTenuringThreshold選項將此值設置爲1。將其設置爲0可立即將年輕代集合中存活的對象移動到舊代。將倖存者比率與期限閾值一起調整。

默認情況下，現代Cassandra版本使用舊版本的Concurrent Mark Sweep（CMS）垃圾收集器;這是通過-XX：+ UseConcMarkSweepGC選項設置的。此設置使用更多RAM和CPU電源在應用程序運行時進行頻繁的垃圾收集，以便將GC暫停時間降至最低。使用此策略時，將堆的最小值和最大值設置爲相同的值非常重要，以防止JVM最初花費大量時間來增加堆。

移動到垃圾第一垃圾收集器

垃圾第一垃圾收集器（也稱爲G1GC）是在Java 7中引入的，作爲CMS GC的改進和最終替代，特別是在具有更多內存的多處理器機器上。

G1GC將堆分成多個相等大小的區域，並動態地將它們分配給eden，survivor和old代，以便每一代都是不需要是內存中連續區域的區域的邏輯集合。這種方法使垃圾收集能夠持續運行，並且需要更少的“停止世界”暫停，這是傳統垃圾收集器的特徵。

G1GC通常需要較少的調整決策;預期用途是您只需要定義最小和最大堆大小以及暫停時間目標。較短的暫停時間將導致GC更頻繁地發生。

G1GC正在成爲Cassandra 3.0版本的默認版本，但作爲JIRA問題CASSANDRA-10403的一部分被撤銷，原因是它對於小於8 GB的堆大小，其性能不如CMS。

如果您想在Cassandra 2.2或更高版本上嘗試使用G1GC和更大的堆大小，可以在cassandra-env.sh文件（或jvm.options）文件中隨時使用這些設置。

尋找G1GC成爲未來Cassandra版本的默認版本，最有可能與Java 9的支持相結合，其中G1GC將成爲Java默認版本。

爲了更深入地瞭解Cassandra節點中的垃圾收集活動，有幾個選項。 cassandra.yaml文件中的gc_warn_threshold_in_ms設置確定將導致Cassandra在WARN日誌記錄級別生成日誌消息的暫停長度。此值默認爲1000毫秒（1秒）。您還可以通過設置cassandra-env.sh或jvm.options文件中的選項來指示JVM打印垃圾收集詳細信息。

Using cassandra-stress

Cassandra附帶了一個名爲cassandra-stress的實用程序，可用於在Cassandra集羣上運行壓力測試。要運行cassandra-stress，請導航到 / tools / bin目錄並運行命令：

$ cassandra-stress write n=1000000
Connected to cluster: test-cluster
Datatacenter: datacenter1; Host: localhost/127.0.0.1; Rack: rack1
Datatacenter: datacenter1; Host: /127.0.0.2; Rack: rack1
Datatacenter: datacenter1; Host: /127.0.0.3; Rack: rack1
Created keyspaces. Sleeping 1s for propagation.
Sleeping 2s...
Warming up WRITE with 50000 iterations...
Running WRITE with 200 threads for 1000000 iteration
...

輸出列出了工具所連接的節點（在本例中爲使用ccm創建的集羣），並創建了一個可以寫入數據的示例鍵空間和表。 通過執行50,000次寫入來預熱測試，然後該工具在繼續寫入時開始輸出度量，爲簡潔起見，我們省略了這些度量。 該工具創建一個線程池（在我的系統上默認爲200），執行一個接一個的寫入，直到它插入一百萬行。 最後，它打印結果摘要：

Results:
op rate                   : 7620 [WRITE:7620]
partition rate            : 7620 [WRITE:7620]
row rate                  : 7620 [WRITE:7620]
latency mean              : 26.2 [WRITE:26.2]
latency median            : 2.6 [WRITE:2.6]
latency 95th percentile   : 138.4 [WRITE:138.4]
latency 99th percentile   : 278.8 [WRITE:278.8]
latency 99.9th percentile : 393.3 [WRITE:393.3]
latency max               : 820.9 [WRITE:820.9]
Total partitions          : 1000000 [WRITE:1000000]
Total errors              : 0 [WRITE:0]
total gc count            : 0
total gc mb               : 0
total gc time (s)         : 0
avg gc time(ms)           : NaN
stdev gc time(ms)         : 0
Total operation time      : 00:02:11

讓我們解開一下。 我們所做的工作是在兩分多鐘內生成並插入一個完全未調整的三節點集羣中的一百萬個值，這表示每秒7,620次寫入的速率。 每次操作的中間延遲爲2.6毫秒，儘管少量寫入花費的時間更長。

現在我們在數據庫中擁有了所有這些數據，讓我們使用測試來讀取一些值：

$ cassandra-stress read n=200000 
...
Running with 4 threadCount
Running READ with 4 threads for 200000 iteration

如果檢查輸出，您將看到它以少量線程開始並且斜坡上升。 在一次測試運行中，它達到峯值超過600個線程，如下所示：

Results:
op rate                   : 13828 [READ:13828]
partition rate            : 13828 [READ:13828]
row rate                  : 13828 [READ:13828]
latency mean              : 67.1 [READ:67.1]
latency median            : 9.9 [READ:9.9]
latency 95th percentile   : 333.2 [READ:333.2]
latency 99th percentile   : 471.1 [READ:471.1]
latency 99.9th percentile : 627.9 [READ:627.9]
latency max               : 1060.5 [READ:1060.5]
Total partitions          : 200000 [READ:200000]
Total errors              : 0 [READ:0]
total gc count            : 0
total gc mb               : 0
total gc time (s)         : 0
avg gc time(ms)           : NaN
stdev gc time(ms)         : 0
Total operation time      : 00:00:14
Improvement over 609 threadCount: 7%

該工具會定期打印出有關最後幾次寫入的統計信息。 前面的輸出來自最後一個統計數據塊。 正如你所看到的，Cassandra的讀取速度幾乎和它寫的一樣快; 平均讀取延遲大約爲10毫秒。 但請記住，這是開箱即用的，未經調整的單線程，在運行其他程序的常規工作站上，並且數據庫大小約爲2 GB。 無論如何，這是一個很好的工具，可以幫助您針對您的環境進行性能調優，並獲得一組數字，指示您的羣集中有什麼期望。

我們還可以通過在yaml文件中創建規範來對我們自己的表運行cassandra-stress。 例如，我們可以創建一個cqlstress-hotel.yaml文件來描述從酒店鍵空間中的表讀取的查詢。 此文件定義了我們用來強調available_rooms_by_hotel_date表的查詢：

keyspace: hotel
table: available_rooms_by_hotel_date

columnspec:
  - name: date
    cluster: uniform(20..40)

insert:
  partitions: uniform(1..50)
  batchtype: LOGGED
  select: uniform(1..10)/10

queries:
   simple1:
      cql: select * from available_rooms_by_hotel_date 
        where hotel_id = ? and date = ?
      fields: samerow             
   range1:
      cql: select * from available_rooms_by_hotel_date 
        where hotel_id = ? and date >= ? and date <= ?
      fields: multirow   

然後我們可以在cassandra-stress運行中執行這些查詢。 例如，我們可能會運行寫入，單項查詢和範圍查詢的混合加載，如下所示：

$ cassandra-stress user profile=~/cqlstress-hotel.yaml 
  ops\(simple1=2,range1=1,insert=1\) no-warmup

與每個查詢相關聯的數字表示所需的使用比率。此命令爲每次寫入執行三次讀取。

關於cassandra壓力的額外幫助

有很多選擇。您可以執行cassandra-stress幫助以獲取支持的命令和選項列表，並使用cassandra-stress help 獲取有關特定命令的更多信息。

您可能還想研究cstar_perf，這是一個由DataStax提供的Cassandra開源性能測試平臺。此工具支持壓力測試的自動化，包括在多個Cassandra版本中啓動集羣和運行性能測試的能力，或者用於比較目的的具有不同配置設置的集羣。它提供了一個基於Web的用戶界面，用於創建和運行測試腳本以及查看測試結果。您可以下載cstar_perf並閱讀http://datastax.github.io/cstar_perf/setup_cstar_perf_tool.html 上的文檔。

總結

在本章中，我們研究了管理Cassandra性能以及Cassandra中可用的設置，以幫助進行性能調整，包括緩存設置，內存設置和硬件問題。我們還設置並使用cassandra-stress測試工具來編寫然後讀取一百萬行數據。

如果您對Linux系統有些新手並且想要在Linux上運行Cassandra（推薦使用），您可能需要查看Al Tobey關於調優Cassandra的博客文章。這將介紹幾種Linux性能監視工具，以幫助您瞭解底層平臺的性能，以便您可以在正確的位置進行故障排除。雖然這篇文章引用了Cassandra 2.1，但它所包含的建議廣泛適用。