卡桑德拉運行內存（堆空間）

我們嘗試了一下與卡桑德拉最近（1.0.7版本），我們似乎有一些問題的內存。我們使用EC2作爲測試環境，我們有三個節點，內存3.7G，核心2.4G，全部運行Ubuntu 11.10。卡桑德拉運行內存（堆空間）

的問題是，我們從舊貨接口擊中節點定期死亡（約後，我們存儲數據的2-2.5G）。錯誤消息：OutOfMemoryError：Java堆空間並根據日誌實際上使用了所有分配的內存。

的節點是相對恆定的載荷下和存儲關於2000-4000行鍵一分鐘，這是通過在10-30行鍵的TRIFT接口一次分批（每個約50列）。讀取次數非常低，每天約1000-2000次，只需要一個單一行密鑰的數據。目前只有一個使用過的列族。

最初的想法是cassandra-env.sh文件中出現錯誤。所以，我們根據節點的規範指定了變量'system_memory_in_mb'（3760）和'system_cpu_cores'（1）。我們還將'MAX_HEAP_SIZE'更改爲2G，將'HEAP_NEWSIZE'更改爲200M（我們認爲第二個與垃圾收集相關）。不幸的是，這並沒有解決問題，我們通過節儉擊中的節點不斷定期死亡。

如果你覺得這個有用，交換關閉，所有3臺服務器上的不可修復內存似乎非常高（2.3GB，我們通常會觀察其他Linux服務器上的不可修復內存量約爲0-16KB）不太清楚不可預測的記憶如何與Cassandra聯繫起來，它只是我們在觀察問題時觀察到的）。 CPU在整個時間都非常空閒。隨着時間的推移，堆內存顯然會逐漸減少，但顯然隨着時間的推移而增長。

任何想法？提前致謝。

來源

2012-04-03 Bill

你在運行什麼版本的Cassandra？另外，您可以將其發佈到Cassandra用戶列表中，因爲它是獲得有關此類事情建議的非常活躍的地方。 – dmcnelis 2012-04-03 14:25:59

感謝您的評論。它是1.0.7。我更新了問題以顯示我們正在運行的Cassandra的版本。我也將搜索Cassandra用戶列表。謝謝。 – Bill 2012-04-04 12:06:09

你是否啓用緩存？行緩存可以真正殺死你的內存。另外，您是否手動指定提交日誌閾值或更改cassandra.yaml中的任何內存內容？ – Zanson 2012-04-09 23:47:42

cassandra-env.sh默認是完美的幾乎所有工作負載，所以直到你知道爲什麼發生這種情況最好把他們帶回自己的缺省設置，也可能使事情變得更糟而不自知。

我在集羣上看到了2k/sec /節點的併發讀寫，所以每分鐘2k-4k寫入的數據非常少，儘管它只是節點接受你正在死亡的連接，這有點奇怪。

如果您的應用程序連接到其他節點的一個節儉的端點是那麼一個死？
客戶端連接使用內存，因此可能值得仔細檢查一次沒有連接太多。在臨死的cassandra節點上的「netstat -A inet | grep 9160」應該告訴你有多少個客戶端連接。很大程度上取決於你的應用程序，你會期望10或100s而不是1000s。

寫道是什麼樣子？
你是否重複寫入相同的行鍵，如果是的話，你是追加新的列名還是覆蓋相同的？
每次寫入有多大？還有什麼可以告訴我的嗎？
如果您覆蓋相同行鍵中相同的列名稱，不斷壓縮可能會很困難。如果您不斷追加新的列名到相同的行鍵，您可能會增加行數太大而無法放入內存。

的「nodetool -h本地主機tpstats」垂死的節點上的輸出也可以提供一些線索，你跌倒哪裏。一直在等待的事情可能是個壞消息，尤其是在這麼低的寫入速度下。

如果您要在生產中使用cassandra，您應該繪製內部圖形以更好地理解發生了什麼。 jmxtrans和石墨應該是你最好的朋友。

來源

2013-04-05 15:56:47 tommyvn

您可以通過問題分享用例describeb的幾個關鍵設置嗎？ – 2013-04-05 16:40:05

有一些事情你可以嘗試調整。首先確保你的列家族沒有行緩存。同樣值得一提的是，檢查日誌中的錯誤和tpstats會導致某些事件因錯誤而死亡，並且某些事情正在隊列中備份。異常的堆棧跟蹤也可能有意義，因爲實際上有不同類型的OOM可能意味着內核調整。

如果您只是爲每個節點使用太多的內存，那麼您希望查看數據集的大小，請嘗試檢查cfstats，您可以大致確定在bloom過濾器上花費了多少空間。由於CF中有更多行，因此可以線性增大，並且是節點所需的基本最小內存的一部分。

nodetool cfstats | grep Bloom.*Used | awk '{ SUM += $5} END { print SUM " bytes" }'

既然你不經常閱讀，你可能會增加他們的誤報率。每個SSTable都有一個bloom過濾器用來檢查一行是否存在於其中。你可以用cqlsh

ALTER TABLE MyColumnFamily WITH bloom_filter_fp_chance = 0.1;

改變後調用升級對CF（這將是緩慢的）每個節點

nodetool upgradesstables MyKeyspace MyColumnFamily

有後果，這哪裏讀，因爲有一個10可能需要較長時間％-ish（.1）的機會，它將檢查SSTables中不存在的行，從而導致額外的磁盤搜索。

如果您有大量行的列族，則另一個主要的存儲區是索引的採樣率。這可以爲每個節點級別的cassandra.yaml

http://www.datastax.com/docs/1.1/configuration/node_configuration#index-interval

如果您有它成立了以堆轉儲上OOM被修改（-XX：+ HeapDumpOnOutOfMemoryError在默認情況下，我相信）應該有一些堆轉儲在/ var/lib/cassandra/data目錄中。你可以用visualvm或者任何你喜歡的工具打開它們來確定堆的哪一部分是在哪裏。

來源

2013-04-07 12:43:53

更新爲Cassandra 2.0：'nodetool cfstats | grep「Bloom。* used」| awk'{SUM + = $ 6} END {print SUM「bytes」}'' – 2013-11-16 22:07:30

卡桑德拉運行內存（堆空間）

回答

相關問題