我剛剛在健康市場科學(xué)（HMS）成立二周年之際，我們幾乎一直在這里與Cassandra一起工作。 那時，我們遇到的問題很少。 就像我曾經(jīng)使用過的其他幾種技術(shù)一樣，Cassandra“行之有效”。

但是，就像我曾經(jīng)使用過的*每一種*技術(shù)一樣，您最終還是會遇到某種問題，即使這不是技術(shù)本身，而是技術(shù)的使用。 這就是這里的情況。 （槍？檢查。腳？檢查。瞄準(zhǔn)……射擊。=）

這是我們的子彈遇見腳的故事...

自從生產(chǎn)以來，我們對Cassandra的依賴程度成倍增加。 我們一直在以越來越高的速度向這些產(chǎn)品線添加產(chǎn)品線和客戶。 并取得了成功，我們不得不隨著時間的推移發(fā)展架構(gòu)，但是系統(tǒng)的某些部分卻一直未受影響，因為它們一直在不斷發(fā)展。 在過去的幾周中，其中一個部分抬起了丑陋的頭。

我們一直在垂直擴(kuò)展集群中的節(jié)點以適應(yīng)需求。 我們的集群完全是虛擬的，因此這始終是阻力最小的路徑。 需要更多內(nèi)存嗎？ 沒問題。 需要更多CPU？ 沒問題。 需要空間/磁盤嗎？ 我們的SAN中有很多東西。 您這樣做的次數(shù)越來越多，而且頻率越來越高，您可能會發(fā)現(xiàn)趨勢并沒有很好地結(jié)束。 =）

首先，隨著我們增加內(nèi)存占用量，我們對以下頁面中的調(diào)整參數(shù)沒有給予足夠的關(guān)注： http : //www.datastax.com/docs/1.0/operations/tuning

給定系統(tǒng)內(nèi)存，我們將堆大小設(shè)置得太大，這開始在Cassandra中引起打ic。 一旦將它帶回在線中，我們又爬了幾個星期。

然后，上周事情到了頂點。 我們在路的盡頭看到了懸崖。 我們在一個客戶端應(yīng)用程序中發(fā)現(xiàn)了一個“錯誤”，該錯誤無意中引入了人工節(jié)流閥。 太棒了！ 我們進(jìn)行代碼更改（兩行代碼），進(jìn)行一些測試，然后將其發(fā)布到生產(chǎn)環(huán)境中。 Bam，我們將并發(fā)性提高了幾個數(shù)量級。 哦，那是什么？ 卡桑德拉cho死了嗎？

卡桑德拉開始Swift收集垃圾。 我們Swift向Google Gods咨詢，并向Oracle（矩陣參考，而非數(shù)據(jù)庫制造商=）尋求建議： http : //www.slideshare.net/aaronmorton/cassandra-sf-2013-in-case-of-emergency-打破玻璃。 如果您尚未閱讀該演示文稿，請在閱讀為時已晚之前閱讀。 對于性能調(diào)整和C *診斷，沒有比Aaron Morton（@aaronmorton）更強(qiáng)大的功夫了。

我們開始研究tpstats和cfstats。 一切似乎都還好。 有什么可以擴(kuò)大我們的足跡？

好吧，我們有很多列族。 我們已經(jīng)改進(jìn)了體系結(jié)構(gòu)和數(shù)據(jù)模型，并且在較新的應(yīng)用程序中，我們采用了虛擬鍵空間方法，使用復(fù)合行鍵將數(shù)據(jù)合并為單個大列族。 但是可惜，遺留數(shù)據(jù)模型仍在生產(chǎn)中。 這些列系列中的許多列流量很少，但是Cassandra仍然為它們保留一些內(nèi)存。 那可能是罪魁禍?zhǔn)?#xff0c;但是那些柱子家族自從開始以來就一直在那里。 我們必須更深入地研究。

我們聽說過Bloom Filter膨脹 ，我們認(rèn)為這可能是問題所在。 但是查看過濾器的磁盤大小（ls -al ** / * Filter.db），所有內(nèi)容看起來都是笨拙的，可以很好地放入我們的巨大堆中。 （ 在1.2中，這些已移出堆 ）

等一下…

當(dāng)我們有一個絕妙的主意來引入一些服務(wù)器端AOP代碼來充當(dāng)觸發(fā)器時，就可以回溯了。 最初，我們使用它們來使索引保持同步：寬行，甚至在某一時刻，我們都使用服務(wù)器端觸發(fā)器使Elastic Search保持最新狀態(tài)。 這使客戶端代碼變得簡單而愚蠢。 連接到C *的應(yīng)用程序不需要了解我們的任何索引編制機(jī)制。

最終，我們發(fā)現(xiàn)最好在應(yīng)用層（通過Storm）控制數(shù)據(jù)流，但是我們?nèi)匀辉诜?wù)器端使用AOP代碼來管理寬行。 盡管我最近一直在反對我們以前的方法 ，但該代碼仍然存在。 這可能是根本原因嗎？ 我們的行肯定會越來越寬……（此時已進(jìn)入數(shù)百萬列）

我們的一個工作人員（對Sandrew表示敬意）找到了JMeter Cassandra，并開始在非生產(chǎn)環(huán)境中進(jìn)行測試。 我們附加了一個探查器，該探查器暴露了我們的問題-內(nèi)部的AOP。 幸運(yùn)的是，我們已經(jīng)在研究從C *中刪除AOP的補(bǔ)丁。 該補(bǔ)丁將AOP代碼移到了客戶端（切點Hector而不是Thrift / Cassandra）。 我們應(yīng)用了補(bǔ)丁并進(jìn)行了測試。

瞧，C *再次嗡嗡作響，從此以后我們所有人都過著幸福的生活。

再次非常感謝+ Aaron Morton的幫助。 你是搖滾明星。 對于HMS的工作人員來說，與這樣一支才華橫溢，熱情洋溢的團(tuán)隊合作是一種榮幸。

很好呀。

參考： 破碎的玻璃：診斷生產(chǎn)Cassandra問題來自我們的JCG合作伙伴 Brian ONeill，網(wǎng)址為Brian ONeill的Blog博客。

翻譯自: https://www.javacodegeeks.com/2013/08/broken-glass-diagnosing-production-cassandra-issues.html

總結(jié)

以上是生活随笔為你收集整理的碎玻璃：诊断生产Cassandra问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。