星火流媒体应用stucks而写，从卡桑德拉阅读/同时

我在做一些基准测试，它由以下数据流：星火流媒体应用stucks而写，从卡桑德拉阅读/同时

卡夫卡 - >星火流 - >卡桑德拉 - > Prestodb

基础设施：我的火花流应用程序运行在4个执行器上（每个内核2个内核4g）。每个执行器都运行在安装了Cassandra的datanode上。 4 PrestoDB工作人员也位于数据节点中。我的集群有5个节点，每个节点都有一个Intel Core i5,32GB DDR3 RAM，500GB SSD和1Gigabit网络。

Spark流应用程序：我的Spark流式批处理间隔为10s，我的kafka制作者每3秒产生5000个事件。我的流媒体应用程序写入2 Cassandra表。

上下文中的一切工作正常：一切正常运行，流应用程序能够处理事件并将它们存储在Cassandra中。批处理间隔是足够的，摄取率，调度和处理延迟在很长一段时间内几乎保持不变。

上下文中的事情变得混乱和混乱：在我的基准测试中，每小时我对Cassandra表执行6次查询。对于运行这些查询的时间，Spark写入Cassandra时，Spark流应用程序不再能够支持写入吞吐量并挂起。

我到目前为止所做的工作：我在其他web帖子（包括stackoverflow）中搜索了这个现象，但是我找不到类似的现象。我见过的最好的办法是增加可用于Cassandra的内存量。其他方面与连接器的读取大小有关，但我不知道这是否是一个问题，因为它只发生在同时读取和写入时。

问题：Cassandra不应该在读取时锁定写入，对吗？你们认为我需要解决的问题的来源（或来源）是什么？我应该考虑哪些配置？

我附加了一个打印a print，说明如前所述，当我使用6个查询运行基准测试时，写入Cassandra表之一的阶段卡住的作业停滞不前。如果您需要更多信息来追踪问题，请随时询问。我很感激！

非常感谢您对我们的支持，

希望我把这个问题以适当的方式，

最好的问候，

卡洛斯

来源

2017-08-02 Carlos Costa

什么堆大小分配给火花执行人和卡桑德拉

最好的问候，

卡洛斯·科斯塔？在查询过程中，您看到GC的堆或使用堆的利用率有所增加吗？还要检查对Cassandra开放的连接数（用于摄取以及查询）？ –

每个Spark执行程序都有4GB的内存。我认为他们有足够的内存来处理这种工作负载，至少在我写这篇文章时似乎绰绰有余。没有错误，没有卡住的工作，没有什么。问题是当prestoDB查询开始在Cassandra表上运行时。当prestoDB工作负载完成后，尽管有几个“暂停”作业，Spark仍能够恢复所有批处理，并且再次正常开始写入Cassandra ... –

... Cassandra堆大小为4GB，HEAP_NEWSIZE为400M。你认为我应该根据自己的工作负载将它碰撞吗？在基准测试期间，我没有检查GC，堆的使用和打开连接，因为它是自动化的，每个小时在夜间......但感谢提示，我将尝试重现场景并立即查看这些方面。至少在寻找什么方面有一个明确的道路是很好的。谢谢你的帮助！ –

这个问题看起来是在卡桑德拉 - 普雷斯托侧并没有因为对星火原因/假设

火花执行人由RM（纱线/ mesos等）来处理你的查询不能直接影响到这一点。在关闭查询期间，如上所述，摄取顺利进行。
只有当您直接与其他组件共享资源时，才会出现Spark端资源匮乏。一般来说，Cassandra，Presto工作者/线程不是使用RM进行分配的，因此他们从节点角度而不是RM角度共享资源。

我怀疑原因摊位可能是，

在查询，Cassandra是读取大量数据，因此JVM内存使用率增加和大量的GC的正在发生。 GC暂停可能是暂停/摊位的原因。
对Cassandra的连接数（读/写）完全由查询使用，因此Spark作业无法插入数据并在队列中等待以获取连接。
节点上的整体资源利用率增加，并且可能有一个组件已达到其限制（CPU，内存，磁盘等）。在这种情况下，IMO CPU，磁盘值得检查。

验证这些原因要么通过监控堆UTIL和GC日志，使用JMX对卡桑德拉，然后撞了这些值取决于可用的资源来解决这个问题，并尝试调整普雷斯托查询打开的连接所以影响最小。

一旦确认Cassandra问题，Presto调整可以作为后面的部分。更多普雷斯托调整可在

https://prestodb.io/docs/current/admin/tuning.html 或者Teradata的解决方案是使用，那么， https://teradata.github.io/presto/docs/current/admin/tuning.html

来源

2017-08-03 06:43:00

非常感谢您的详细回复@Nachiket凯特！我首先看CPU的使用情况（使用顶级），我认为这可能是问题的最大来源。查看其中一个节点，cpu使用情况如下：cassandra进程（〜280％）; presto（〜90％）;火花（3.3％）。由于我使用英特尔酷睿i5四核CPU，我认为在这些节点上Spark流作业没有更多空间，因为Cassandra和Presto会导致CPU匮乏。我想我会试图找出如何限制Cassandra cpu的使用。再次感谢您的时间和关注。这有很大的帮助。 –

很高兴我可以帮助:)不知道你是否使用Yarn，但如果是的话，那么你可以使用队列限制摄入资源，Cassandra和Presto可以在Linux中使用cgroups进行限制。 –

我不知道这有什么关系与卡桑德拉。

什么是Spark scheduling策略配置？默认情况下，它是FIFO。暗示，查询作业可能会消耗所有内核，直到完成。而且，将会使流媒体工作挨饿。如果FIFO，更改为FAIR并再试一次。

来源

2017-08-02 16:26:43 jagsr

谢谢你的提示，Spark的调度策略留给它的默认值（FIFO）。我只使用Spark进行流媒体作业。查询我正在使用PrestoDB。因此，除非PrestoDB让Spark流媒体作业陷入瘫痪，否则我更倾向于使用Cassandra内存或写入/读取性能/并发，正如@Nachiket Kate指出的那样。监视这些场景相对困难，我会尝试再次模拟上下文，并查看是否可以进行更多观察。谢谢你的协助。 –

只是为了完成这个问题，以下是由堆栈溢出成员，很友好地给我的提醒回复：

1）我将Cassandra的jvm.options中的Java垃圾收集器更改为G1，不需要像默认CMS那样进行调整。 http://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsTuneJVM.html#opsTuneJVM__setting-g1-gc 我改变了它，因为GC暂停在相似的情况下经常被指出为一个问题。说实话，我对GC监控并不太熟悉，但Datastax Cassandra文档告诉我要使用G1。我改变了它，并且我发现我的工作负载和基础架构在性能和稳定性方面有所提升。

2）我意识到我对群集的性能感到乐观，并且在Cassandra上运行繁重的prestoDB查询时，每10秒处理和写入Cassandra 20 000个事件几乎是不可能的。 PrestoDB和Cassandra正在使用我节点中几乎所有的CPU。我在每个节点只有4个核心。 Cassandra的CPU使用率接近280％，Presto接近90％，因此Spark流媒体执行者在那里挨饿。此外，Cassandra没有更多的空间来适应这种写入速度，火花传输工作开始挂起，并在很长一段时间内累积数批。因此，我将批次间隔设置得更高。我知道你失去了一些数据的时效性，但是如果基础设施无法处理，我没有资源去扩展：（

另一种可能性是通过使用linux cgroups，纱线cpu隔离和队列来优化CPU限制，例如，看看它是否有帮助，对于我的集群，如前所述，我认为这个问题实际上是试图“用小型遥控车来移动montain”:)每个节点都负责火花流工作+ cassandra + presto ，只有4个内核可用。 3）最后，我还调整了火花Cassandra连接器，这对我的工作负载起作用，但我认为这取决于您的数据和其他变量。我改变了： *并发写数从5到2; *从“分区”到“replica_set”将grouping.key分组，因为我的分区键具有很高的基数（它们在RDD中几乎是唯一的），因此根据分区键对批次进行分组毫无用处。但这当然取决于你的分区密钥。 * batch.size.rows为50.但这可能取决于您为每个流式微批处理的数据量。 https://github.com/datastax/spark-cassandra-connector/blob/master/doc/reference.md

我希望这篇文章可以帮助其他人面临流大数据项目有困难的，因为事情可能会变得非常非常困难的，有时:)如果我的一些决定也错误或误导性的，请让我知道。每一个帮助表示赞赏。

谢谢大家，

来源

2017-08-03 15:45:05

星火流媒体应用stucks而写，从卡桑德拉阅读/同时

回答

相关问题