碎玻璃：诊断生产Cassandra问题

我刚刚在健康市场科学（HMS）成立二周年之际，我们几乎一直在这里与Cassandra一起工作。那时，我们遇到的问题很少。就像我曾经使用过的其他几种技术一样，Cassandra“行之有效”。

但是，就像我曾经使用过的*每一种*技术一样，您最终还是会遇到某种问题，即使这不是技术本身，而是技术的使用。这就是这里的情况。（枪？检查。脚？检查。瞄准……射击。=）

这是我们的子弹遇见脚的故事...

自从生产以来，我们对Cassandra的依赖程度成倍增加。我们一直在以越来越高的速度向这些产品线添加产品线和客户。并取得了成功，我们不得不随着时间的推移发展架构，但是系统的某些部分却一直未受影响，因为它们一直在不断发展。在过去的几周中，其中一个部分抬起了丑陋的头。

我们一直在垂直扩展集群中的节点以适应需求。我们的集群完全是虚拟的，因此这始终是阻力最小的路径。需要更多内存吗？没问题。需要更多CPU？没问题。需要空间/磁盘吗？我们的SAN中有很多东西。您这样做的次数越来越多，而且频率越来越高，您可能会发现趋势并没有很好地结束。 =）

首先，随着我们增加内存占用量，我们对以下页面中的调整参数没有给予足够的关注： http : //www.datastax.com/docs/1.0/operations/tuning

给定系统内存，我们将堆大小设置得太大，这开始在Cassandra中引起打ic。一旦将它带回在线中，我们又爬了几个星期。

然后，上周事情到了顶点。我们在路的尽头看到了悬崖。我们在一个客户端应用程序中发现了一个“错误”，该错误无意中引入了人工节流阀。太棒了！我们进行代码更改（两行代码），进行一些测试，然后将其发布到生产环境中。 Bam，我们将并发性提高了几个数量级。哦，那是什么？卡桑德拉cho死了吗？

卡桑德拉开始Swift收集垃圾。我们Swift向Google Gods咨询，并向Oracle（矩阵参考，而非数据库制造商=）寻求建议： http : //www.slideshare.net/aaronmorton/cassandra-sf-2013-in-case-of-emergency-打破玻璃。如果您尚未阅读该演示文稿，请在阅读为时已晚之前阅读。对于性能调整和C *诊断，没有比Aaron Morton（@aaronmorton）更强大的功夫了。

我们开始研究tpstats和cfstats。一切似乎都还好。有什么可以扩大我们的足迹？

好吧，我们有很多列族。我们已经改进了体系结构和数据模型，并且在较新的应用程序中，我们采用了虚拟键空间方法，使用复合行键将数据合并为单个大列族。但是可惜，遗留数据模型仍在生产中。这些列系列中的许多列流量很少，但是Cassandra仍然为它们保留一些内存。那可能是罪魁祸首，但是那些柱子家族自从开始以来就一直在那里。我们必须更深入地研究。

我们听说过Bloom Filter膨胀，我们认为这可能是问题所在。但是查看过滤器的磁盘大小（ls -al ** / * Filter.db），所有内容看起来都是笨拙的，可以很好地放入我们的巨大堆中。（在1.2中，这些已移出堆）

等一下…

当我们有一个绝妙的主意来引入一些服务器端AOP代码来充当触发器时，就可以回溯了。最初，我们使用它们来使索引保持同步：宽行，甚至在某一时刻，我们都使用服务器端触发器使Elastic Search保持最新状态。这使客户端代码变得简单而愚蠢。连接到C *的应用程序不需要了解我们的任何索引编制机制。

最终，我们发现最好在应用层（通过Storm）控制数据流，但是我们仍然在服务器端使用AOP代码来管理宽行。尽管我最近一直在反对我们以前的方法，但该代码仍然存在。这可能是根本原因吗？我们的行肯定会越来越宽……（此时已进入数百万列）

我们的一个工作人员（对Sandrew表示敬意）找到了JMeter Cassandra，并开始在非生产环境中进行测试。我们附加了一个探查器，该探查器暴露了我们的问题-内部的AOP。幸运的是，我们已经在研究从C *中删除AOP的补丁。该补丁将AOP代码移到了客户端（切点Hector而不是Thrift / Cassandra）。我们应用了补丁并进行了测试。

瞧，C *再次嗡嗡作响，从此以后我们所有人都过着幸福的生活。

再次非常感谢+ Aaron Morton的帮助。你是摇滚明星。对于HMS的工作人员来说，与这样一支才华横溢，热情洋溢的团队合作是一种荣幸。

很好呀。

参考： 破碎的玻璃：诊断生产Cassandra问题来自我们的JCG合作伙伴 Brian ONeill，网址为Brian ONeill的Blog博客。