cassandra生產(chǎn)監(jiān)控

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

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

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

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

我們一直在垂直擴展集群中的節(jié)點以適應需求。 我們的集群完全是虛擬的，因此這始終是阻力最小的途徑。 需要更多內(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。 一旦將它帶回在線中，我們又爬了幾個星期。

然后，上周事情到了頂點。 我們在路的盡頭看到了懸崖。 我們在一個客戶端應用程序中發(fā)現(xiàn)了一個“錯誤”，該錯誤無意中引入了人工節(jié)流閥。 太棒了！ 我們進行代碼更改（兩行代碼），進行一些測試，然后將其發(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）更強大的功夫了。

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

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

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

等一下…

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

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

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

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

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

很好呀。

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

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

cassandra生產(chǎn)監(jiān)控

總結(jié)

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

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