NoSpamLogger.java最大內存使用量達到了Cassandra

我擁有一個Cassandra的5節點集羣，每個節點上的複製因子爲3時約有650 GB的數據。我最近開始在/ var/log /卡桑德拉/ SYSTEM.LOG。NoSpamLogger.java最大內存使用量達到了Cassandra

INFO [ReadStage-5] 2017年10月17日17：06：07887 NoSpamLogger.java:91 - 達到（1.000GiB），最大存儲器使用不能分配1.000MiB的塊

我試圖增加file_cache_size_in_mb，但遲早會出現這種相同的錯誤。我曾試圖爲這個參數高達2GB，但無濟於事。

當錯誤發生時，CPU使用率增加，讀取延遲非常不穩定。我每半小時就會看到一次這種激增。請注意下面列表中的時間安排。

INFO [ReadStage-5] 2017-10-17 17：06：07,887 NoSpamLogger.java:91 - 達到的最大內存使用量（1.000GiB），無法分配1.000MiB的塊大小 INFO [ReadStage-36] 10-17 17：36：09,807 NoSpamLogger.java:91 - 最大內存使用量達到（1.000GiB），無法分配1.000MiB塊大小 INFO [ReadStage-15] 2017-10-17 18:05:56,003 NoSpamLogger.java： 91 - 最大內存使用量達到（2.000GiB），無法分配1.000MiB塊大小 INFO [ReadStage-28] 2017-10-17 18:36:01,177 NoSpamLogger.java:91 - 最大內存使用量達到（2.000GiB），不能分配大塊1.000MiB

我有兩個表是按小時分區的，分區很大。防爆。以下是nodetool表它們的輸出統計

Read Count: 4693453 
    Read Latency: 0.36752741680805157 ms. 
    Write Count: 561026 
    Write Latency: 0.03742310516803143 ms. 
    Pending Flushes: 0 
     Table: raw_data 
     SSTable count: 55 
     Space used (live): 594395754275 
     Space used (total): 594395754275 
     Space used by snapshots (total): 0 
     Off heap memory used (total): 360753372 
     SSTable Compression Ratio: 0.20022598072758296 
     Number of keys (estimate): 45163 
     Memtable cell count: 90441 
     Memtable data size: 685647925 
     Memtable off heap memory used: 0 
     Memtable switch count: 1 
     Local read count: 0 
     Local read latency: NaN ms 
     Local write count: 126710 
     Local write latency: 0.096 ms 
     Pending flushes: 0 
     Percent repaired: 52.99 
     Bloom filter false positives: 167775 
     Bloom filter false ratio: 0.16152 
     Bloom filter space used: 264448 
     Bloom filter off heap memory used: 264008 
     Index summary off heap memory used: 31060 
     Compression metadata off heap memory used: 360458304 
     Compacted partition minimum bytes: 51 
     **Compacted partition maximum bytes: 3449259151** 
     Compacted partition mean bytes: 16642499 
     Average live cells per slice (last five minutes): 1.0005435888450147 
     Maximum live cells per slice (last five minutes): 42 
     Average tombstones per slice (last five minutes): 1.0 
     Maximum tombstones per slice (last five minutes): 1 
     Dropped Mutations: 0 



    Read Count: 4712814 
    Read Latency: 0.3356051004771247 ms. 
    Write Count: 643718 
    Write Latency: 0.04168356951335834 ms. 
    Pending Flushes: 0 
     Table: customer_profile_history 
     SSTable count: 20 
     Space used (live): 9423364484 
     Space used (total): 9423364484 
     Space used by snapshots (total): 0 
     Off heap memory used (total): 6560008 
     SSTable Compression Ratio: 0.1744084338623116 
     Number of keys (estimate): 69 
     Memtable cell count: 35242 
     Memtable data size: 789595302 
     Memtable off heap memory used: 0 
     Memtable switch count: 1 
     Local read count: 2307 
     Local read latency: NaN ms 
     Local write count: 51772 
     Local write latency: 0.076 ms 
     Pending flushes: 0 
     Percent repaired: 0.0 
     Bloom filter false positives: 0 
     Bloom filter false ratio: 0.00000 
     Bloom filter space used: 384 
     Bloom filter off heap memory used: 224 
     Index summary off heap memory used: 400 
     Compression metadata off heap memory used: 6559384 
     Compacted partition minimum bytes: 20502 
     **Compacted partition maximum bytes: 4139110981** 
     Compacted partition mean bytes: 708736810 
     Average live cells per slice (last five minutes): NaN 
     Maximum live cells per slice (last five minutes): 0 
     Average tombstones per slice (last five minutes): NaN 
     Maximum tombstones per slice (last five minutes): 0 
     Dropped Mutations: 0

這裏所說：

cdsdb/raw_data histograms 
Percentile SSTables  Write Latency  Read Latency Partition Size  Cell Count 
           (micros)   (micros)   (bytes)     
50%    0.00    61.21    0.00   1955666    642 
75%    1.00    73.46    0.00   17436917    4768 
95%    3.00   105.78    0.00   107964792    24601 
98%    8.00   219.34    0.00   186563160    42510 
99%   12.00   315.85    0.00   268650950    61214 
Min    0.00    6.87    0.00    51     0 
Max   14.00   1358.10    0.00  3449259151   7007506 

cdsdb/customer_profile_history histograms 
Percentile SSTables  Write Latency  Read Latency Partition Size  Cell Count 
           (micros)   (micros)   (bytes)     
50%    0.00    73.46    0.00   223875792    61214 
75%    0.00    88.15    0.00   668489532   182785 
95%    0.00   152.32    0.00  1996099046   654949 
98%    0.00   785.94    0.00  3449259151   1358102 
99%    0.00   943.13    0.00  3449259151   1358102 
Min    0.00    24.60    0.00    5723     4 
Max    0.00   5839.59    0.00  5960319812   1955666

可否請你建議了一種方法來緩解這個問題？

來源

2017-10-17 Varsha

你可以給我們這些表的「nodetool cfhistograms」嗎？ – dilsingi

我在問題中發佈了直方圖。 – Varsha

根據張貼的cfhistograms輸出，分區是巨大的。

raw_data表的95％百分位數的分區大小爲107MB，最大的爲3.44GB。 customer_profile_history的95％百分位數分區爲，大小爲1.99GB，最大爲5.96GB。

這顯然與您每隔半小時注意到的問題有關，因爲這些巨大的分區被寫入到sstable中。數據模型必須根據分區大小進行更改，最好使分區間隔爲「分鐘」而不是「小時」。所以2GB的分區將減少到33MB的分區。

推薦的分區大小是保持最大接近100MB。雖然理論上我們可以存儲超過100MB，但性能會受到影響。請記住，每個分區的讀取操作都是通過電線超過100MB的數據。在你的情況下，其超過2GB，因此所有的性能影響。

來源

2017-10-23 14:38:41 dilsingi

精彩!!感謝您指出了這一點。在同樣的說明中，重新分區這個大表的最簡單方法是什麼？我是否需要創建一個新表格並重新輸入數據。或者，還有更好的方法？ – Varsha

奇怪的是，更大的分區表「customer_profile_history」只有大約10GB的數據，而其分區仍然可以改進的「raw_data」表大約爲594GB。所以我會首先專注於重新創建前一個表並使用批量加載器（也稱爲sstableloader）加載數據。您可以使用相同的過程重新加載第二個表格數據，或者如果您熟悉，請考慮使用火花加載。 – dilsingi

@Varsha如果沒有任何後續問題，請記住接受答案（刻度線）。 – dilsingi

NoSpamLogger.java最大內存使用量達到了Cassandra

回答

相關問題